At the risk of having this blog begin to read like a FAQ, let me begin once again with the words, "folks have been asking me...". So:
Folks have been asking me, what is DNSCurve and what's ISC's position on it given our long involvement in DNSSEC? This is a reasonable thing to wonder about since both DNSSEC and DNSCurve concern themselves with the security of DNS. However, they solve different problems, in spite of the similarity of their names. In this article I'll try to explain what these technologies do and answer the question, "why would I want either one?"
DNSSEC is an Internet Standard meaning that it came from IETF, took years longer than it should have, was designed by committee, has some features that almost nobody now remembers the reason for, and lacks some features that almost everybody wishes it had. So, it's a lot like IPv6 or IPSEC or anything else that's been through the standards process. And yet, it works.
The problem statement for DNSSEC was: "how can we protect DNS content from third party modification?" The first parties in this case are the the zone administrator who produces the primary zone content and the ultimate end user or application who consumes that content. Third parties include Dan Kaminsky or anyone else who might bombard a client with spoofed replies attempting to guess transaction ID's and port numbers; secondary name server operators or hackers who break into those systems; recursive name server operators who may want to rewrite www.google.com to their own search page or to rewrite negative responses to point to their own advertising servers; firewall and IDS operators who might want to rewrite all answers containing profanity or pornography or other illicit content to point at a walled garden. From DNSSEC's point of view, only the zone administrator should be able to produce content within the namespace of a zone. There are no exceptions.
The solution statement from DNSSEC is therefore: "add data authenticity as a function of the domain name system."
For DNSCurve, the problem statement is different so is its proposed solution. DNSCurve protects the channel between an authority nameserver (so, a primary or secondary nameserver for some zone) and the recursive nameserver. This is the same channel that's protected by UDP port number randomization, and the only attack it protects against is Dan Kaminsky's spoofed flood attack. Noteworthy here is that DNSCurve was invented by the same person who invented UDP source port randomization -- Dan Bernstein. DNSCurve also uses different math than DNSSEC, something called "elliptic curve cryptography" which is really interesting since the keys and signatures are so much smaller than those used in DNSSEC. Bernstein has developed Curve25519 which is very fast. We'll need real crypto math people (of whom I am not one) to be Bernstein's second set of eyes on this but I'm betting that Curve25519 will turn out to be as good as it looks.
DNSCurve's solution statement is therefore: "let's do an even better job of protecting recursive nameservers against Dan Kaminsky, by using strong crypto rather than just random transaction ID's and random UDP port numbers."
For myself, I remain puzzled by the existence of DNSCurve, because it solves a problem that I'm not having any more -- UDP source port randomization is good enough to take the Dan Kaminsky spoofed-flood class of attack completely off the table. I'm also puzzled because DNSCurve completely fails to address problems I am still having, such as that a secondary nameserver might be hacked, or a recursive nameserver operator might redirect me to their search page instead of Google's or might redirect me to their advertising server rather than giving me correct negative answers, and a nation-state might redirect me to their walled garden if they think I'm trying to access something they don't want me to access.
I want provably correct DNS content to be universally available. Not just for me but for the entire population of the Internet. I want to stamp out all forms of DNS intermediation whether by recursive nameserver operators or nation-states or hackers. Because DNSSEC can do this, ISC has invested a lot of time and money over the last dozen years helping to develop DNSSEC. Because DNSCurve does not do this, and because the problems DNSCurve actually does solve are pretty well solved by UDP source port randomization and will be entirely eradicated by DNSSEC, ISC is not investing in DNSCurve at all.
- BIND 10
- Other Software Projects
- security advisories
- software forums
- ABOUT ISC