I've implemented DNSSEC twice now, I've also implemented IPv6 several times - at various levels of the stack (including directly at layer 3) and have had a hand in two different SSL/TLS implementations. Having implemented each, I don't think that DNSSEC is particularly difficult or error-prone compared to IPv6 or SSL - it's probably far less complicated than both. The trickiest part of DNSSEC to get right is probably NSEC3 (on both the authoritative side and the validating side) and it's not so bad if you brush up on trees and hashing.<p>But DNSSEC can still be very difficult to implement, not so much because of its inherent complexity, but because of a mismatch between assumptions the designers made and what real-world implementors require. Here's a simple example; many DNS implementations for large service support "m of n" answers. E.g. you might have 100 IP addresses for a service, and the DNS implementation would choose say 8 IP addresses to hand-out. The dogma of DNSSEC is that answers should be signed-offline, which is great for security, but it means that in cases like this that we'd have to deal with a combinatorial explosion and sign all 186 billion potential answers. We could also sign online, but doing expensive crypto in response to a DNS request isn't very smart if you'd like to survive DDOS attacks. So implementers have to make trade-offs and add complexity to make things work.<p>DNS is also commonly used as a routing mechanism - but DNSSEC does nothing to validate that this routing is being handled correctly. Signed answers are replayable - so the answer that says "You should go to the Dublin node" can be fed to resolvers/clients that should really be routed to a different node. This can aid attacks higher up the protocol stack that depend on routing traffic along a path it can observed. Similarly, because DNSSEC queries happen in the plain, intermediaries can easily filter and drop particular queries which they don't like.<p>Most bizarrely perhaps, is that DNSSEC provides no end-to-end security. Your browser or OS still communicates with your resolver using regular queries, relying on a single unauthenticated bit to "request" validation. It's as if LAN/wifi-level abuse wasn't a concern at all, or that public resolvers (like OpenDNS and Google Public DNS) didn't exist.
The proposition that it has failed due to the passage of 17 years since the first RFC neglects the fact that there were certain key events that inhibited adoption that didn't happen until recently:<p>1. The DNS Root Zone was not signed until mid-2010. As the anchor of trust for the DNS, deployment prior to this date was basically experimental. This was the commencement of production use.<p>2. Registries and registrars, as a whole, did not support it until recently. However, ICANN has required them to do so in the last few years so this roadblock is being removed.<p>The assertion that it is a failure may ultimately prove to be true, but looking at its experimental phase and declaring it as proof positive is not convincing.
> Another security mechanism in widespread use is HTTPS. This has been available since around 1994, and has gotten a refresh with TLS in 2000. Like SSH many web masters don’t really care how this work, they just know to get certificates from Certificate Authorities, put some lines into their configuration files and it works.<p>No, it doesn't work[1]. There's only the illusion of CA certification security and nothing more. So if the argument here is that <i>DNSSEC failed because it's not like OpenSSL CA</i> I'm not really buying it - that said I reckon that it's better for software to be easier to configure but as man with white hair and weird look in his eyes said <i>things should be as simple as possible, but not more</i>.<p>[1] <a href="https://www.youtube.com/watch?v=pDmj_xe7EIQ" rel="nofollow">https://www.youtube.com/watch?v=pDmj_xe7EIQ</a>
While we're cataloging security technologies that have failed, we should add S/MIME-based email encryption to the heap. (Well, except for those organizations that have centrally-managed keys and infrastructure for internal email encryption.)<p>I know that some savvy users encrypt email, but in the age of the NSA, payload-encrypted email should be the <i>default</i> case.
Dammit! I was 24 hours away from posting my DNSSEC post! You win this time...<p>For what it's worth, the first KEY/SIG/NXT DNSSEC draft dates back to 1994(!)
Some registrars, particularly Network Solutions, offer poor support for DNSSEC records, or anything beyond A and CNAME records really. For a long time it was officially unsupported; lately there is a footnote at the bottom of the advanced DNS options page to call tech support if you want to discuss using DNSSEC---although they'll happily sell me an extended validation certificate....
For my private domains I use zonesigner from dnssec-tools. No database, no additional daemons, doesn't need to be run on the same machine as the DNS server. It takes the input zone file and keys; spits out a signed zone file. Couldn't be any simpler.<p>DNSSEC will IMHO be like IPv6 and it will see some adoption after a long march.
For me one of the most important insights: The reason for the (claimed) failure: It is to difficult to use.<p>That is one trouble I see so often in the computer business. Some invention is made with bright ideas and good intentions, but it is doomed to fail or at least to produce unnecessary additional costs, just because of one reason: It is unnecessary complicated.<p>Some bright guy (I don't remember who) said: Make it as simple as possible, but not simpler. That is the art, to find the right measure of complexity and make it as simple as possible. Somebody else said, that something is only than finished, when there is nothing left to delete from it.
I'm not entirely sure what's so difficult about dnssec?<p>I just use dnssec-keygen, then include the two keys in my zonefile, named-compilezone to sanitize, and it does the needful?
The author compares DNSSEC with other protocols like SSH and HTTPS.<p>DNSSEC suffers from some of the same problems as SSL PKI, namely
1. it requires placing authority in people who you may not trust and
2. it's too easy to make configuration mistakes.<p>But I suggest those alone are not the reasons DNSSEC has "failed".<p>The reason it was a failure from the beginning (cf. the other protocols the author mentions) is in my opinion because it's aimed at authentication, and _only_ at authentication. And of course, like PKI, it tries to do this by delegating authority to some mysterious group of people.<p>If it were aimed at _both_ encryption and authentication like SSH or SSL, then it could "fail" at authentication but still appear useful for encryption.<p>In an ideal world, you could _authenticate_ with 100% certainty that you are connecting to a given remote computer and you could eliminate the MITM risk.<p>We know that this is pure fantasy in today's world, though we try our best.<p>Moreover, with respect to DNS, ICANN's and other third party DNS is usually anycasted, so what exactly are we authenticating with DNSSEC?<p>Certainly not "the" remote computer with the zone file. Who is in charge of assigning a "root server" IP address to some interface on some computer in some datacenter sitting between you and the rest of the internet? Do you even know?<p>Perhaps we are authenticating that the domainname is "legitimate"?<p>According to who? Some third party? ICANN? It sounds a lot like PKI and SSL certificates.<p>Personally, I would not rely on DNSSEC to confirm the existence/nonexistence of any domainname.<p>If I can get a publicly available zone file from a trusted source, then I can serve that "root" and "TLD" information locally on the device. No need for the network.<p>What I'm more interested in is confirming that the answer I receive from the authoritative nameserver (not the root or the TLD) contains the correct information, e.g., the correct IP address.<p>Why shouldn't DNS traffic be encrypted, like, e.g., TCP/HTTP traffic?<p>Going forward, I find dnscurve much more appealing than DNSSEC.<p>It might not be a foolproof solution to authentication, but at least it offers encryption.<p>The same can be said for SSH and SSL.<p>To the author: Maybe that's why they have not been complete failures like DNSSEC.
Well, please argue it then.<p>Please provide evidence that it – deployment – failed, not that it is hard to understand (69 pages of training books and multi-day training courses are understanding issues, not deployment).<p>I mean, it became possible to fully secure things end-to-end since 2010[1], so in about 10 years from now by your length of time theory, we should know how it works out.
If you have domain registration and DNS hosting from the same company, then it should ideally be possible to log in, check a box, and have all the keys and records computed and updated automatically.<p>Is there a single registrar in the world that supports this?