DNSSEC vs. DNSCurve
February 27 2010 by 
Cricket Liu (Infoblox)
With the recent announcement that OpenDNS will support DNSCurve, I've begun hearing more questions about it. In particular, people wonder whether DNSCurve is a viable alternative to DNSSEC. They've generally heard that DNSCurve is simpler to set up than DNSSEC and involves less overhead.
Unfortunately, DNSCurve isn't an alternative to DNSSEC - although it could conceivably complement DNSSEC, in ways I'll discuss.
You can think of DNSCurve as a clever scheme for bootstrapping secure communications between name servers, a bit like automatically setting up a TSIG key for use between any two name servers. To communicate securely, a recursive name server can use public key information embedded in the domain name of an authoritative name server to derive a session key. The communications, then, can be encrypted for privacy, authenticated and integrity-checked.
One thing DNSCurve doesn't do is protect data sitting in a name server's cache. It secures the channel between two name servers, but if your name server retrieves records from the cache of an untrusted recursive name server, DNSCurve gives it no way to authenticate those records. DNSSEC, of course, does, as those records would be accompanied by an RRSIG record that digitally signed them.
Likewise, if a hacker compromises an authorized authoritative name server, DNSCurve can't protect name servers that query that name server: The responses continue to validate. With DNSSEC - assuming the hacker didn't gain access to the zone's private key - the hacker wouldn't be able to produce valid signatures for the zone data.
Finally, the difference between the amount of support for DNSCurve and DNSSEC is startling. OpenDNS's implementation of DNSCurve is, by their own admission, the only existing DNSCurve implementation so far. Despite their announcement of support for DNSCurve, their recursive name server currently doesn't use DNSCurve to secure any communications, because there are no authoritative name servers that speak DNSCurve. Today, an interested, committed DNS admin would have to write his own implementation of DNSCurve to deploy it.
DNSSEC is supported in the latest versions of BIND, the Microsoft DNS Server, NSD, and Unbound, as well as in many products based on those name servers.
But what frustrates many of us in the DNS community isn't what DNSCurve doesn't do, it's what it does. Specifically, DNSCurve is distracting DNS administrators from the important work of deploying DNSSEC. We've labored for 15 years to address misgivings about the DNSSEC specifications, provide a choice of implementations that support DNSSEC, pressure the administrators of the upper levels of the Internet's namespace to take on the hard work of signing their zones, and rally legions of DNS administrators. And, just as we gain traction and begin to make headway, DNSCurve comes along, claiming to offer an alternative, when in fact it solves different problems.
In an ideal world, DNSCurve could act as a powerful complement to DNSSEC, providing channel authentication and privacy that DNSSEC alone doesn't offer. We'd finish the roll out of DNSSEC, begin deploying DNSCurve, and enjoy the best of both. But DNSCurve's backers seem committed to derailing DNSSEC's progress in favor of DNSCurve. If they succeed, the Internet will be the worse off for it.
Posted in DNSSEC | DNS Security | 
17 comments
Mar 1, 2010 at 3:32 PM
DNSCurve is about transport security, which is 90% of the threat posed to DNS *right now*.
I agree that DNSSEC will be wonderful in 10 more years when it is deployed enough to be useful.
Mar 1, 2010 at 4:12 PM
Speaking personally, the "circle the wagons" attitude to DNSCurve from the incestuous DNSSEC community is embarrassing.
And I think the problem is that IT administrators see right through it.
And I don't know which DNSCurve backers are committed to derailing DNSSEC's progress, as it certainly isn't OpenDNS. We've said publicly and I'll say it again here, we will absolutely support DNSSEC when we see demand and traction.
And while I'm commenting, there are various ISC employees (like Alan Clegg) who state publicly that we have some financial motivation against DNSSEC, but of course that makes no sense and we do not. In fact, we have Fortune 1000 customers paying us for DNS, and when they ask us for DNSSEC, we'll offer them that, too.
Mar 1, 2010 at 8:14 PM
I'm sorry you think that my attitude is embarrassing, David. And that I'm part of an "incestuous DNSSEC community." (If I'm a member, do I at least get a tee shirt?) I thought that I was motivated by an interest in making the Internet's DNS infrastructure more secure, but apparently I'm mistaken.
Mar 2, 2010 at 7:34 AM
China & the USA will soon be migrating to a modern Object-Oriented platform.
Security is Designed in NOT Bolted On.
The Big Lie Society is an embarrassment to all humans.
It is interesting to see that they view "Distractions" as derailing their lack of traction, after 15? years stuck in the same tired ditch.
Mar 2, 2010 at 7:55 AM
Cricket,
I can appreciate your opinions and expertise, but your article seems to have an "us vs them" tone. I am not sure if that was intentional, but it is there. I enjoyed the technical discussion about how the DNSSec and DNSCurve differ and ask myself, "Why is DNSCurve a 'bad' thing if it can be part of the solution to the increasingly vulnerable and threatened DNS infrastructure?"
Given that the two technologies appear to complement each other, I would expect to see companies like Infoblox and OpenDNS support and implement them both. I wholeheartedly agree that DNSCurve is not the whole solution, but is a great layer of security to add to the other layers, like DNSSec, strong security policies, and education of both IT administrators and the general public.
Thanks for the post about this topic. I had seen the "DNSCurve" posting from OpenDNS, but had no idea what it is. This overview was helpful for that.
Respectfully,
Chris Gauthier
Mar 2, 2010 at 8:28 AM
"us vs them"
With THE Big Lie Society there is only ONE WAY - THEIR Way.
The new DNS stores domains in Flash Memory in edge devices.
WRT-54GL & WRT-160N are examples.
There is no central server.
With an Object-Oriented Platform
and DHTs Distributed Hash Tables,
builtin not bolted on, the game changes.
Unfortunately, some people think they are a success wasting the world's time for 15+ years. What has been the cost of that nonsense?
Mar 2, 2010 at 9:29 AM
Cricket,
Thank you for the overview and the reasoning.
The gentleman who said 90% is in the transport is just plain wrong. Cache poisoning is not a transport issue.
An object oriented platform is a measure of security.
Distributed hash table are alright, if authenticated.
I then wonder how many enterprises use WRT-54GL and 160N for their production networks. Also storing does not mean authenticated before storing and that a major point of DNSSEC to begin with.
Mar 3, 2010 at 3:37 PM
>Cache poisoning is not a transport issue.
Really? I could have sworn that the implementation of the cache poisoning was done by injecting bogus "response" packets to a recursive. Seems to me that weakness was definitely at the transport layer.
Mar 5, 2010 at 9:38 AM
By the end of March 2010, DNSSEC) will/should be deployed within the .edu portion of the Internet, which EDUCAUSE manages under a cooperative agreement with the U.S. Department of Commerce.
Soon enough it DNSSEC will be used throughout all higher education and likely be required by all those that work with higher education, so the steam still exists.
I feel like Cricket's message was partially out of frustration with people misleading and those people being mislead to believe that DNSCurve fixes the problems, when it really "seems" to be ONLY a piece of the larger puzzle.
We are a community with different needs but a single goal. We need a secure reliable DNS. If any piece is left unsecured, then no piece is secure. You cannot screw down all the windows, lock all the doors and leave a key on a nail.
I think we can all agree that the entire Internet is not perfect, but we certainly cannot throw-out security just because Vint Cerf was an excellent scientist and not an excellent psychic.
In the interest of full disclosure, I am an Infoblox user and quite proud of what we have done with it; however I'd feel the same way if I was still running ISC free code.
Mar 12, 2010 at 6:18 PM
I agree with what Mike said. DNSCurve is all about transport security which is threat posed to DNS *right now*.
DNSSEC is a make work project and distraction we don't need. DNSSEC solves a problem that does not exist.
Mar 18, 2010 at 6:38 PM
I am a bit confused as well by David's "circle the wagons" comment. As one of those "IT administrators" I had a lot of trouble seeing through anything related to the DNSCurve/DNSSEC "debate" because so much of the discussion is based on a false dichotomy.
Simply put, there is nothing preventing anyone from implementing both DNSSEC and DNScurve in the same installation. It's simply misleading (though understandable) to say "DNScurve *vs.* DNSSEC." They're orthogonal.
I think where the circle-the-wagons attitude comes from is a response to DNScurve proponents who spend most of their time trying to vilify DNSSEC. In his blog announcing DNScurve for OpenDNS, Matthew Dempsky, who is otherwise doing excellent work implementing and standardizing DNScurve, spends 8 out of 11 paragraphs stating (and in some cases mis-stating) why DNSSEC is bad.
DNScurve itself is not a distraction, rather it is the focus of DNScurve's advocates on what's allegedly wrong with DNSSEC that is the distraction. Why not instead let DNScurve stand on its own?
Besides, I think it would be fun to try to implement both.
Mar 19, 2010 at 7:59 PM
Mike - it's not about DNScurve v. DNSSEC - it's more about DNSSEC v. DNScurve. DNScurve cares nothing about DNSSEC. It simply fixes the problem with the UDP transport security issues.
DNSSEC on the other hand is more of a make work project that's going to cost trillions of bucks economically to "make work". But if DNScurve gets implemented DNSSEC gets left out in the cold. People don't want complexity when they can have simplicity. In that way DNScurve wins hands down over DNSSEC.
So expect more of the DNSSEC v. DNScurve marketing tactics from the BIND and iSociety boys.
In my opinion all this chatter of DNS this versus DNS that avoids the issue. We need DNS security today. The time for chatter has come and gone. DNScurve offers the solution we need to ensure transport security. DNSSEC does not do that.
Mar 23, 2010 at 7:27 AM
It sounds like DNScurve could be described as similar to IPv5; a step in the right direction from IPv4 to IPv6 (DNSSEC)? ;)
Mar 23, 2010 at 8:02 AM
Tristan I have no idea with respect to DNS security in IPv5. DNScurve works over IPv4 or IPv6. DNScurve is simply a means to ensure transport security i.e. that the host you contacted for DNS is in fact the host that responded and not a third party attempting to hijack the connection.
Mar 23, 2010 at 8:19 AM
Joe - Sorry, my attempt at humor failed. I was making the analogy that perhaps DNSCURVE is an intermediate step to full DNSSEC implementation. You get some of the benefits without the high cost of DNSSEC.
For example, people have been claiming IPv6 as the necessary future for 10 years, but it is moved very slowly.
(BTW - There is no IPv5, it was a creation of my mind to fit this analogy)
Mar 23, 2010 at 12:56 PM
Actually - there was an IPv5 - at least the name was proposed.
Yes - now I understand the joke.
Yes - IPv6 has taken years to adopt. I think most of the issues there are with the RIRs. They should be giving them away not charging outrageous rates for them. But I digress.
You are correct. DNSSEC will take years to adopt. Most people won't bother. It's a massive economic cost to business.
If DNScurve is adopted I predict DNSSEC will go poof. No one wants the overhead when DNScurve offers all the security that's required.
Jul 26, 2010 at 2:01 PM
Getting both dnssec and dnscurve would be great. At the moment any end user dnssec doesn't validate and dnscurve would far more easily apply for protecting all (key management/rollover issues + users who haven't got caches make dnssec difficult to apply truly end-end and even then it hasn't reached saturation yet).
Dnscurve could fill that gap quickly but at the moment you have to choose dnscache with dnscurve or unbound with dnssec. And everyone would have to use Opendns or a slower ssh/ipsec.
At the moment dnscurve is best for end systems and caching resolvers with dnssec + ssh/dnscurve for the authoritys.
The crtiticism and lack of understanding of dnscurve by the isc is embarassing.
Dnssec should also learn very quickly how much more efficiency and dos prevention could be gained by analysing dnscurve.
Dnssec is a difficult task to get right with lots to consider, but they are quite far off the mark in many respects.
Both are really needed, dnssec for less secure servers and dnscurve for all (sniffed traffic jeopardising ssl etc.).
Roll on dnssecurv