Home / Blogs

OpenDNS Adopts Proposed DNS Security Solution: DNSCurve

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.


  • Complexity: DNSSEC has many options for enabling/disabling DNSSEC validation, with conflicting interpretations of how to handle different bits; considering people still disagree about how to handle features of DNS that have been present since its inception, I foresee these won’t be resolved anytime soon.
  • DNS traffic: Responses right now are usually limited to 512 bytes, sometimes a little more. DNSSEC enabled responses regularly exceed 1500 bytes, requiring IP fragmentation or fallback to TCP. IP fragmentation frequently fails with misconfigured firewalls and using TCP is much slower than the default UDP transport.
  • Questionable security practices: Most users are encouraged to use 512-bit or 1024-bit RSA keys. A group of hobbyists recently worked together to break all of the 512-bit keys used by Texas Instruments for signing their calculator firmware and they did so quickly and easily. The RSA company and NIST have been recommending users switch to 2048-bit keys since 2003 and 2007, respectively. Again, unfortunately, the DNSSEC standards developers are hesitant because bigger crypto is slower, and it will further push the traffic size issue.
  • Hamstrings modern uses: High traffic DNS servers can’t handle signing every response packet, so they need to pre-compute signatures. This limits how companies like Akamai and Google or projects like the NTP Pool can use DNS for global load balancing and routing users to their nearest servers. It also fundamentally hampers services like OpenDNS, which use DNS to provide content filtering and search services.
  • Efficiency: RSA is a very slow crypto standard; its only benefit is that everyone knows about it. DNSSEC can theoretically support other crypto standards, but the IETF has largely ignored efforts from interested parties to add support for faster and stronger algorithms.

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.)

Filed Under


summary from comp.protocols.dns.bind Carl Byington  –  Feb 25, 2010 1:31 AM

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

dig http://www.google.com @

http://www.google.com.      30     IN     CNAME   google.navigation.opendns.com.
google.navigation.opendns.com. 30 IN   A
google.navigation.opendns.com. 30 IN   A

That is NOT the answer that google is handing out:

dig http://www.google.com @ns1.google.com

http://www.google.com.      604800 IN     CNAME   http://www.l.google.com.
http://www.l.google.com.    300   IN     A
http://www.l.google.com.    300   IN     A
http://www.l.google.com.    300   IN     A
http://www.l.google.com.    300   IN     A

As DNSCurve is still a recent proposal, Matthew Dempsky  –  Feb 25, 2010 2:03 AM

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.

Facts. David Conrad  –  Feb 25, 2010 5:29 PM

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 Joe Fox  –  Feb 26, 2010 3:32 PM

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".

Not a straw man argument Carl Byington  –  Feb 26, 2010 6:14 PM

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.

don't confuse bad logic with a good technical observation Joe Fox  –  Feb 27, 2010 3:21 PM

@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.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix