DNSCurve: Usable security for DNS

DNS database espionage

The myth of public DNS databases

DNS administrators, unhappy with the exposure of information that they want to keep private, began disabling public AXFR. Surveys by the Measurement Factory showed that half of the second-level DNS zones in .com had disabled public AXFR by 2005 and that 70% had disabled it by 2008.

Of course, attackers can guess domain names by trial and error, but this is much slower than seeing a complete list. Flooding a 4-megabit-per-second connection with guesses for an entire day allows only about 2²⁹ guesses.

The NXT-walking attack against ancient DNSSEC

"NXT walking" is an easy attack against the version of DNSSEC specified in RFC 2065. The attacker asks webmd.com about the 26 names a.webmd.com, b.webmd.com, etc. The server returns various NXT records: for example, in response to d.webmd.com, it returns "there are no names between cancer.webmd.com and data.webmd.com", leaking the existing names cancer.webmd.com and data.webmd.com. The attacker then sends another round of queries, probing any remaining gaps between the leaked names. After a few rounds of queries, consuming not much more traffic than an AXFR request, the attacker knows all of the names within webmd.com.

In other words, by installing DNSSEC, an administrator would be exposing his complete DNS database, even if the administrator had turned off AXFR.

RFC 2065 stated "It is part of the design philosophy of the DNS that the data in it is public and that the DNS gives the same answers to all inquirers" and did not comment on this attack.

The NSEC-walking attack against old DNSSEC

RFC 4033 included, and mandated, an "NSEC" record that exposed just as much information as NXT. As before, by installing DNSSEC, an administrator would be exposing his complete DNS database, even if the administrator had turned off AXFR.

RFC 4033 admits that DNSSEC "introduces the ability for a hostile party to enumerate all the names in a zone by following the NSEC chain. NSEC RRs assert which names do not exist in a zone by linking from existing name to existing name along a canonical ordering of all the names within a zone. Thus, an attacker can query these NSEC RRs in sequence to obtain all the names in a zone." Even though this information disclosure is clearly the fault of the DNS server, RFC 4033 claims that "this is not an attack on the DNS itself."

The NSEC3-walking attack against current DNSSEC

NSEC3 exposes hashes of DNS names in the same way that NSEC exposes the original DNS names. A hash is 150 iterations of SHA-1. Imaginary example: Upon receiving a request for crackedribs.webmd.com, the webmd.com DNS server would return a signed NSEC3 record saying "there are no names whose hashes are between 71f64b7c9418fac530999c3a267f457a and 72461131da8439570e3a2230f7523533."

"NSEC3 walking" is an easy privacy-violating attack against the current version of DNSSEC. After a few rounds of requests to a DNSSEC server, the attacker has collected a list of hashes of existing names. The attacker then guesses a name, hashes the guess, checks whether the hash is in the list, and repeats. This is much, much, much faster than sending a guess through the network: in a single day a low-cost 2.4GHz Core 2 Quad CPU can compute more than 2^41 SHA-1 iterations (using OpenSSL; a tuned implementation would be even faster), enough to check 2^34 guesses. A 100-computer lab can check 2^40 guesses per day. A large company or botnet can check 2^50 guesses per day.

In other words, compared to normal DNS, current DNSSEC (with NSEC3) makes privacy violations thousands of times faster for casual attackers, or millions of times faster for serious attackers. It also makes the privacy violations practically silent: the attackers are guessing names in secret, rather than flooding the legitimate servers with guesses.

NSEC3 is advertised as being much better than NSEC. It's true that NSEC is even worse than NSEC3: "instantaneous" is faster than "2^40 or 2^50 guesses per day". However, NSEC3 is much worse than DNS without DNSSEC.

How does DNSCurve help?

Version