|
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.
Details
So while debate about DNSSEC wears on, OpenDNS has fully adopted another proposed DNS security solution: DNSCurve.
DNSCurve is a recent DNS extension proposal that is fully backwards compatible with the existing DNS protocol, uses much stronger cryptography than DNSSEC, and most importantly, is much simpler and much easier to implement and manage. The most significant technical distinction is that DNSSEC uses large and slow per-recordset signatures while DNSCurve uses small and fast per-packet encryption and authentication.
OpenDNS’s DNS resolvers already fully support DNSCurve today and use it whenever possible. Of course, authoritative servers need to be upgraded to support DNSCurve as well, but it’s our hope that this announcement will help to get the ball rolling on DNSCurve adoption. If you’re an authoritative DNS provider and are interested in deploying DNSCurve, we’re interested in hearing from you.
(This article was originally posted to the OpenDNS blog.)
Sponsored byWhoisXML API
Sponsored byDNIB.com
Sponsored byCSC
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byVerisign
See the “OpenDNS today announced it has adopted DNSCurve…” thread on comp.protocols.dns.bind for more details on this. I will summarize some of it here for those of you that don’t read that group.
“It (dnssec) also fundamentally hampers services like OpenDNS, which use DNS to provide content filtering and search services.”—Matthew Dempsky
“So, DNSSEC is bad because it prevents OpenDNS from lying… (“Search services” is a code word for “legitimate response modification”.)”—Stephane Bortzmeyer
“If OpenDNS really believe that DNScurve is the way of the future, why don’t they have such NS records for opendns.com?”—Chris Thompson
So we have a proposal (dnscurve) that has only one implementation, no documented standard that anyone else can use to produce an interoperable implementation, and that does not prevent recursive resolvers from lying to their clients (giving answers that are anything other than the answers that the authoritative servers would have given).
“Follow the money. OpenDNS has fought against DNSSEC because it prohibits their “Intelligent Navigation” (Typo correction) and redirection of google… They “approve” of DNScurve because it can be subverted.”—Alan Clegg
resolver1.opendns.com has address 208.67.222.222
dig http://www.google.com @208.67.222.222
;; ANSWER SECTION:
http://www.google.com. 30 IN CNAME google.navigation.opendns.com.
google.navigation.opendns.com. 30 IN A 208.67.219.230
google.navigation.opendns.com. 30 IN A 208.67.219.231
That is NOT the answer that google is handing out:
dig http://www.google.com @ns1.google.com
;; ANSWER SECTION:
http://www.google.com. 604800 IN CNAME http://www.l.google.com.
http://www.l.google.com. 300 IN A 66.102.7.105
http://www.l.google.com. 300 IN A 66.102.7.104
http://www.l.google.com. 300 IN A 66.102.7.147
http://www.l.google.com. 300 IN A 66.102.7.99
As DNSCurve is still a recent proposal, it's expected that there wouldn't be many implementations yet. However, the protocol is fully documented on dnscurve.org, and there's an IETF Internet-Draft documenting it as well. As to the accusations of "lying" in DNS responses, OpenDNS users are in full control over what kind of DNS responses they receive. The defaults were chosen to provide the experience the majority of our users want. That said, our issue with DNSSEC is simply that it's not an appealing solution to us right now and implementing it today would not provide any additional benefit to our users. We're still open to the possibility of implementing DNSSEC support in the future should it prove useful.
As far as I am aware, DNSCurve was first proposed by Dan Bernstein in August 2008. I suppose that is recent, at least in comparison to DNSSEC, however I don't believe the lack of implementations is a result of how young the proposal is. After all, there are numerous protocols that have been implemented with their proposals or soon after. The fact that users have control does not contradict the fact that OpenDNS servers are "lying" (in the sense that an answer is being synthesized that is different than the answer returned by the source authoritative for the data). Having had some exposure to developing DNSSEC, I can understand your reticence at investing in doing the implementation yourself. DNSSEC implementation is non-trivial and I can understand the business reasons why you'd like to delay as much as possible. However, implementing DNSSEC would have benefit to your users -- if signed DNS data is corrupted between the authoritative source and the OpenDNS resolver, DNSSEC would allow detection of that corruption. You may not consider that benefit worth the cost, but that does not mean the benefit does not exist.
It is probably the case that OpenDNS has a "vested interest" in supporting DNScurve over DNSSEC due to the fast and loose way they perform DNS resolution to steer people where they want. HOWEVER, that in no way diminishes whatever technical and security merits that may apply to DNSSEC and DNScurve. There are excellent points to be made -- both pro and con. To dismiss DNScurve simply because of OpenDNS's DNS steering is actually a "straw man argument".
Rather than being a straw man argument, this is fundamental to the concept of what it means “to secure” dns. I take that to mean that the end-client user can use the dns answers to prove that the answer he was given is actually the answer that the owner of the domain wants him to see. DNSSEC can achieve this, DNScurve cannot.
@Carl: You bring up an excellent technical point about a capability that DNSSEC has that DNScurve does not. Nevertheless, OpenDNS’s support for DNScurve over DNSSEC, and the possible reasons for doing so in order to meet a non-technical agenda, do not in any way legitimately argue either pro or con as to the technical merits of DNScurve versus DNSSEC.