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.
