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