Everyone in the DNS community agrees that DNS’s security model is woefully outdated. Conceived at a time when there were fewer computers on the Internet than are housed by even today’s smallest data centers, DNS unfortunately has no strong protection against malicious parties hoping to exploit web users. What little protection it does offer is mostly derived from novel uses of non-security features (e.g., UDP source port and transaction ID randomization).
For more than 15 years, the IETF has been working on DNSSEC, a set of extensions to apply digital signatures to DNS. Millions of dollars in government grants and several reboots from scratch later, DNSSEC is just starting to see real world testing. And that testing is minimal — only about 400 of the more than 85,000,000 .com domains support DNSSEC, fewer than 20% of US government agencies met their mandated December 31, 2009 deadline for DNSSEC deployment, and only two of the thirteen root zone name servers is testing with even dummy DNSSEC data.
Aside from its lack of adoption, DNSSEC isn’t even a very satisfactory solution. It adds tremendous complexity to an already fragile protocol, significantly increases DNS traffic in size, encourages questionable security practices, and hamstrings many modern uses of DNS.
DNSCurve is more like TLS for DNS servers, in comparison to DNSSEC, which is signed records. DNSCurve uses point-to-point cryptography to secure communication, while DNSSEC uses pre-calculated signatures to ensure the accuracy of the supplied records.
So we can summaraize it like this: DNSSEC: Accurate Results DNSCurve: Encrypted Traffic
Theoretically you can use traffic encryption to ensure accuracy, the way TLS does for websites. Except that it’s not really the encryption that’s ensuring your accuracy, is the authentication provided through the PKI. And there’s a set of critical problems with the basic DNSCurve PKI.
The first problem here is that with DNSCurve, each and every DNS server involved needs a private key, and since the key signature is encoded into the resolver’s address, then in the case of anycast DNS servers, each server needs the same private key. But even if they use different keys, you’re still trusting the local security where the DNS Server is installed. If the server is installed somewhere hostile, then the results can be compromised. This is not true with DNSSEC.
ICANN has stated that, in the case of the DNS Root zone servers, DNSCurve will not be implemented, ever. Many of the root servers operate in less-trusted locations, and the potential for abuse by local governments would be enormous. This is precisely why DNSSEC was designed such that signing happens outside the DNS server. DNS relies on a vast network of server which may not be individually trustworthy, so DNSSEC was designed such that the trust is based solely on the informationthey serve, not the honesty of the operator.
The second problem is that DNSCurve secures the public key by encoding it into the resolver name. But DNSSEC does not sign the resolver name. This means that DNSSEC (which is implemented in the root zone) cannot be used as a trust root for DNSCurve, because the one thing that DNSCurve requires to be accurate is in fact the very thing for which DNSSEC cannot ensure accuracy.
So essentially DNSCurve is pretty much a non-starter. While it can be used to guarantee the security of your communication with a single DNS resolver, there currently is no way of globally anchoring your trust in a way that could guarantee the accuracy of any results you retrieve.
Unless DNSCurve is re-designed to allow for trusted key distribution, it will have to remain a client-side security tool rather than a tool for ensuring the authenticity of DNS records.
Since DNSCurve is relatively new and was developed largely by djb in isolation, presumably these show-stopping issues were simple oversights on his part, and may be fixed at some future date. Though given Dr. Bernstein’s track record of maintaining his inventions, I wouldn’t hold my breath.