With root, pir's .org and godaddy now all supporting dnssec, perhaps wikimedia domains can lead the way ? We would be the largest .org and being the only .org in the web property top 10, thus the largest website deployment in the world of dnssec, if I'm not mistaken.
Some planning advice:
http://www.securityweek.com/deploying-dnssec-four-ways-prepare-your-enterprise-dnssec
Version: unspecified
Severity: enhancement
Seems like there is no DNSSEC in place
http://dnssec-debugger.verisignlabs.com/no.wikipedia.org
Perhaps it is time to consider this?
Our current DNS server implementation (gdnsd), which we like for a lot of its other unique features (and which I should incidentally disclaim that I'm the author of, although that started long before I became an employee here), does not support DNSSEC at all, but there is a long-oustanding github ticket about it. Some my earlier commentary about it in that ticket is somewhat-relevant for the issue of deploying it here in the general case as well: DNSSEC is not all roses; there are some drawbacks, too. It's probably inevitable, but it's a major project.
I second this issue. DNSSEC is a major improvement, especially for a site like wikipedia which needs to be constantly on guard for censorship and intimidation.
Regarding the DNS server, lack of DNSSEC would seem to be a type 1 issue for a server underpinning something like wikipedia. Both BIND and unbound support it, so upgrading to a more standard implementation may be appropriate at this time.
I've tried in the past to keep myself fairly open to the eventual inevitability of DNSSEC and keep my comments even-handed on the matter. I was willing to capitulate to mass opinion if the rest of the Internet grudgingly agreed that it was better-than-nothing and adopted it robustly. Regardless, I and/or we haven't had time to work on it either at the gdnsd level or the WMF organization level anyways.
I think that, over time, my opinion of DNSSEC has only gotten worse (it was never good to begin with), and I think increasingly there's some real momentum against it out there aside from just a quiet few of us. I'm not sure at this point whether it actually is a good idea to invest in this, even if we did have the time for it.
I think this does a better job tearing down DNSSEC than I could do on my own (the rest of the page too, but the comments at the linked section in particular):
https://ianix.com/pub/dnssec-outages.html#misc
I can't think of any of our other major backlog items I'd prioritize DNSSEC over, and I hope the issue goes away on its own before we get around to it.
Since we haven't updated this in two years, I figured I should post again:
The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all such tickets that haven't been updated in 6 months or more. This does not imply any human judgement about the validity or importance of the task, and is simply the first step in a larger task cleanup effort. Further manual triage and/or requests for updates will happen this month for all such tickets. For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!