Editor’s note: Below is a fairly technical post from OpenDNS engineer and noted security researcher Matthew Dempsky introducing DNSCurve and sharing some thoughts on DNSSEC. Readers of this blog know Matthew has been credited with finding vulnerabilities in both Adobe Flash Player and djbdns.

Everyone in the DNS community agrees that DNS’s security model is woefully outdated. Conceived at a time when there were fewer computers on the Internet than are housed by even today’s smallest data centers, DNS unfortunately has no strong protection against malicious parties hoping to exploit web users. What little protection it does offer is mostly derived from novel uses of non-security features (e.g., UDP source port and transaction ID randomization).

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, we’re excited to announce that 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.

Editor’s note: Our support for DNSCurve doesn’t prevent our adoption of DNSSEC — they are not mutually exclusive. While we have reservations about DNSSEC, we can and will implement it when we see more demand and traction, but in the meantime, when we see a viable technology that can be quickly implemented to improve security for DNS users, that’s a no-brainer in our book.

  • Joe Watson

    Wow, this sounds very reasonable to me dude.


  • The DNScurve web site doesn’t appear to have any links to a proper protocol specification nor any implementations.

  • Ok, we’re an authoritative DNS provider that uses OpenDNS for Resolution, how do we implement DNSCurve?

  • Will OpenDNS be providing DNSCurve related statistics?

  • jamieson

    part of the problem is that the dnscurve (DJB) people are split on the whole matter against the BIND people – both see the answer as their own – reminds me of the old gnome vs kde wars etc.

  • As a Systems Administrator for a company that uses OpenDNS for our DNS Forward Lookup, is there anything we need to do to take advantage of DNScurve on the OpenDNS network? We run Microsoft Active Directory using their built-in DNS.

  • How will we as end-users of OpenDNS benefit from this?

  • Tony Finch: The dnscurve.org website documents the protocol. There’s also an Internet-Draft on the IETF website (draft-dempsky-dnscurve) describing it in IETF form.

    J. Breeden: Because DNSCurve is a new proposal, software support for it is still in development. Your best bet right now is to voice your interest in DNSCurve to the developers of your DNS software.

    B. Johns: We don’t have anything specific planned yet, but we’re definitely interested in it.

    Kevin Murray: Nope, DNSCurve just affects traffic between our servers and authoritative DNS servers, so there’s nothing to do on the client side. 🙂

  • m

    Enabling dnssec is simple. Just turn it on in the config file, and make sure you’ve got the right keys. On an anverage, this will improve security. One can’t have both perfect security and perfect backwards compatibility.

    The packet size argument is FUD because djb does not like EDNS0. Any modern DNS software except djb software does UDP datagrams up to MTU and beyond.

    2048 bit RSA keys are doable. Shorter keys can indeed be used if key rollovers (especially ZSK rolls which are automatable) are adjusted accordingly.

  • Hi Matthew, nice job. That this will get the ball rolling towards a widely spread implementation of DNSCurve.

    I was wondering whether you also did some work on the authoritative side, regarding DNSCurve.

  • Maciej Zenczykowski

    I’m a big fan of DNSCurve since it’s such a clean protocol – I hate the extreme complexity and weaknesses + uselessness of DNSSEC), so I’m really very glad to hear this.

    Is there an open source implementation/library (preferably very liberally licensed) that could be pulled into other DNS servers wholesale to make them dnscurve aware, both as clients and as servers? Preferably with a howto implement dnscurve doc…

    You should probably upgrade the authoritative dns servers for opendns.com then – currently:
    $ host -t ns opendns.com auth1.opendns.com
    opendns.com name server auth1.opendns.com.
    opendns.com name server auth2.opendns.com.
    opendns.com name server auth3.opendns.com.
    you are returning non-dnscurve resolvers.

    And to play the devil’s advocate… how are you planning on protecting the weak link between your recursive servers and your clients?

  • chojrak11

    Instead of wasting CPU power on complicated algorithms used by DNSSEC, requiring all your clients to change software, you can provide better security using DNSCurve which is simpler in design, and far more efficient in terms of server and network load.

    And did Matthew mention that there was already at least one bug in BIND related to DNSSEC?

    Not only the protocol is complicated and flawed. Its implementation is also flawed.

  • I still can’t find *any* software that implements DNScurve, nor any mailing lists for discussing it. It looks like vapourware to me, especially when compared to DNSSEC’s multiple interoperating implementations and widespread real-world deployment activity.

  • Pingback: OpenDNS adopts DNSCurve » Managing DNS()

  • Just saw this from Comcast.


  • Chip

    So what exactly does this support mean?

    Under DNSSEC, the recursive resolver will set the AD bit on the response to the client if the DNSSEC data has been validated. What happens when OpenDNS validates a DNSCurve query? Is the same AD bit set?

    If verification fails, is the query simply dropped? Does the end user see the same sort of NXDOMAIN redirection as if the qname doesn’t exist?

  • Operational implementation of DNSCurve is imperative to stem the deployment of a very seriously flawed political and technical rollout of a repeatedly failed protocol otherwise known as DNSSEC.

    Critical mass determines the standards, beginning with wide-spread adoption and operational depoloyment across the spectrum, which evolves into a de facto standard, and eventual adoption in the face of complete abandonment by the special interest groups which have been cramming DNSSEC down the throats of us – the providers of Internet Services to the public at large.

    This force feeding has resulted in projectile regurgitation on the part of the victims, and I for one cannot wait until DNSCurve completely supplants the ‘evil-doers’ – AKA, the proponents of DNSSEC!

  • Brian

    Just read a post regarding Comcast’s move to DNSSEC and found this excerpt intersting;


    …Comcast believes that DNSSEC won’t be compatible with their current domain redirection service. Most ISPs now use these services, which redirect people who type in non-existent or misspelled URLs, to an advertisement-laden search portal. It essentially creates a new revenue stream off of your butterfingers, and according to Comcast — they’re going to have to disable it to make this security upgrade work (it makes you wonder if an ISP would avoid the update for the sake of a few bucks).

    “We believe that DNSSEC is basically incompatible with current DNS redirect technology,” says Comcast’s DNS guru Chris Griffiths. “We have always known this and we expect that one result of turning on DNSSEC validation will be that Domain Helper’s DNS redirect functionality will need to be disabled, absent any additional IETF standards work or other technology advances,” he says, “and we’re not aware of any work on either of these fronts.”

    Does this play a role in the decision to back DNSCURVE over DNSSEC?

  • R. P.


    DNSSEC is too heavy, too complex. We need an alternative.

  • Nicholas Weaver

    I can understand not wanting to validate DNSSEC in the recursive resolver (after all, the biggest value of DNSSEC is that you don’t have to trust the DNS recursive resolver, and the second biggest is that it is a PKI).

    But why does OpenDNS refuse to even support DO (DNSSEC OK) queries? Instead, OpenDNS is just stripping the request and contacting the authority without EDNS and DO.

    This is somewhat unusual behavior, as most resolver software will maintain a DO request from the client to the authority.

    Also, DNSCurve overall buys very little actual security for DNS. The dirty little secret of DNS security is, against a MitM, the end protocol using DNS is either trivially vulnerable, OR never trusted the results returned by DNS.

    Thus DNSCurve, assuming good protection against out of path adversaries (port randomization and glue policy), only provides an increase in security against a MitM when the MitM is a MitM on DNS but not on the final protocol, which is a rare case indeed, except when you consider the recursive resolver as untrustworthy.

  • Rick Leir

    You said “High traffic DNS servers can’t handle signing every response packet”. Just a suggestion: use a PS3 running Linux. It has 7 co-processors and a gigabit interface. Some software development would be needed to distribute the work.

    There are likely faster solutions than this, but not likely cheaper ones. What am I missing?
    Thanks — Rick

  • Michael Sheldon

    I’m curious as to how key rollover is to be implemented for authoritative servers? By reading the IETF Draft, I see no signal from the client as to the identity of the key used for encryption, leaving me to believe that if more than one key is in place, the server will have to blindly attempt to decrypt with one key, then if it fails, try the next until one succeeds or all fail? Assigning a new IP address for every key rollover would be the other possibility, but is not really practical.

  • Chip: DNSCurve doesn’t use DNSSEC’s AD bit. It offers transport security, so the goal is to make it impossible for third parties to forge responses.

    Brian: Somewhat, but we also think DNSCurve is a just a more practical solution than DNSSEC. If DNSSEC does end up getting a significant market share to make DNSSEC validation worthwhile to implement, we’ll pursue that as well.

    Nicholas Weaver: Saying we’ve “refused” to support DNSSEC seems silly to me. There’s no deployed user base for DNSSEC-validating stub resolvers, so what would be the point except to make packets larger, consume additional cache and CPU resources, and gratuitously break misconfigured but working clients?

    Rick Leir: The point really is that an RSA signing computation at a comparable security level to the elliptic-curve Diffie-Hellman computation used by DNSCurve is at least an order of magnitude slower.

    Michael Sheldon: Yes, those are the key rollover options. As a mitigating factor, DNSCurve chooses to use much, much more secure public key cryptographic primitives than DNSSEC, so key rollovers can be much less frequent.

  • mark
  • Michael Sheldon

    I would highly suggest a method of applying a short ID to the keys that is passed along in the transaction.

    While I agree that cryptographically there is far less need for key rollover, There are other reasons for key rollover than the result of direct cryptanalysis or brute force. Especially with the private keys needing to be kept at the edge of the network instead of in a protected core, the risk of key disclosure from internal and external attacks is higher than with DNSSEC. Thus, in practical terms, the frequency of key rollovers is probably about the same, in spite of the better algorithm.

  • Michael Sheldon: My feeling for most organizations is that using a second IP address for key cycling will be entirely manageable. For small organizations that host their own DNS but don’t have any spare IP addresses, trying one of two keys for a small rollover period is perhaps suboptimal, but not deal breaking, IMO: it’s possible to support two keys at once using only about 20% more CPU than supporting just one key (by sharing computational work between the two Diffie-Hellman operations).

  • Great job OpenDNS!

  • Michael Sheldon

    Multiple IP addresses is probably practical for the middle-sized guy up to the large non-ISP. But for the very large authoritative providers it’s just not feasible IMO. And let’s face it, if you don’t get buy in from enough authoritatives, its use is limited.

    On the one hand, I like the philosophy of DNSCurve. It’s far more practical as a protocol than DNSSEC for all but the most critical applications (if I was a bank, I think I’d want both). It’s also theoretically much simpler to implement and maintain.

    However, IMO, it’s not ready for prime-time from a maintainability point. Key rollover is a fact of life no matter how good the encryption, and re-configuring the IP address as a means of effecting rollover shows a lack of consideration for real-world use. I would consider the current implementation to be a good proof of concept.

  • John in Dublin

    Matthew will home computer/small business users of OpenDNS need to install a DNSCurve cache on their pcs/laptops to avail of this added level of security? And if so given DNSCurve cache software is not yet available what benefit is your adoption of DNSCurve to the home computer/small business users of OpenDNS?

  • Michael Sheldon: My feeling for most organizations is that using a second IP adxress for key cycling will be entirely manageable. For small organizations that host their own DNS but don’t have any spare IP addresses, trying one of two keys for a small rollover period is perhaps suboptimal, but not deal breaking, IMO: it’s possible to su-port two keys at once using only about 20% more CPU than supporting jusg one key (by sharing computational work between the two Diffie-Hellman operations).;

  • L M Dillon

    In response to Kevin Murray, you say …”there’s nothing to do on the client side.” Does this mean that I CAN’T use dnscurve to thwart my ISP from snooping on my DNS queries coming from my small network, which uses OpenDNS as the forwarders? My ISP IS the “man in the middle” who modifies and snoops on my DNS queries.

  • David Robarts

    DNSSEC = trusted DNS data from untrusted connections and servers (you can verify that the data came from an authorized source). However DNSSEC does not provide any privacy, may cause backward compatibility issues, and exposes some zone enumeration vulnerability (risk reduced by hashing).

    DNSCurve = trusted connection between DNS servers (is it not possible to implement DNSCurve at the client?). Data on a DNSCurve server may be polluted if DNS data upstream was not protected by DNSCurve.

    If I understand it correctly, the insecure DNS system scales well because most requests are handled by caching DNS servers – the information may have been handled by several DNS servers between the authoritative server and the client. DNSCurve is only compatible with such scaling to the extent that all upstream DNS servers are trusted. It seems like for very large zones DNSSEC is the better option for this reason; however, on smaller branches of the DNS tree, DNSCurve may provide protection with lower overhead.

    As a site owner, DNSSEC seems more appealing because only upstream zone authorities need to be trusted (i.e. example.com trusts .com and the root DNS) whereas DNSCurve relies on all the servers between my server and the client (as well as all the servers between server of each upstream zone and the client).

  • Pingback: Why DNSSEC May Not be a Good Thing « UNIX Administratosphere()

  • Pingback: OpenDNS, DNSCurve And You()

  • James Jamson

    That’s really awesome and all, but what can I do as an end user?? DNScurve protects the last mile, and assuming your databases are not compromised, I’ll get to the right place. But how do I do this? I do make my PC support DNScurve?

    Of course OpenDNS needs to support anti-poisoning mechanisms. For example, caching only from un-poisoned servers or using DNSsec to the root servers. A chain is only as strong as its weakest link..

  • Great job!

    We recently switched our entire VoIP infrastructure to support DNSCurve. It just makes sense from a security perspective.

    The whole idea of someone spoofing our DNS and hijacking our customer’s calls (or spying to calls via “VoIP MITM”) just makes me feel sick. 😛

    We have been recommending DNSCurve to all of our customers and anyone who will listen to reason.

    FYI: We are noticing that about 12% of our total DNS queries are using DNSCurve now. (Mostly from OpenDNS’s servers. lol!)

  • With all the security breaches in the last couple of years, it would only make sense to switch to the DNSCurve. DNS security should be a top requirement especially for businesses.

  • Don’t worry.

    It will only take one rogue script-kiddie to bring the planet to its knees. I’m guessing he’ll launch a tool but not know how far it will go. When an heir to the Philip Morris fortune launched an email virus early on, it literally crashed the Internet (or what passed for it at the time). He didn’t realize how fast it would spread or how often it would replicate.

    Shortly after the damage is done, we’ll have a secure system in place. People have a history agreeing on a solution AFTER a disaster.

  • Yes, DNS’s security model is outdated. What it going to take to change that? Perhaps some massive security breach. Then as usually we’ll make a knee-jerk reaction.

    Just like airport security, someone wears bombs on their shoes, suddenly we have to have our shoes checked. Why are we always one step behind?

  • I totally agree with @Paula on the aspect of DNS’s security model being outdated. Its what they bring out next that i am vigilant about. It better be more impressive and high tech than the former. Take for example airport security. The technology within needs to be re-examined in my opinion.

  • The DNS team is working hard, May god help them