DNSCurve: Usable security for DNS

Negative DNS forgery

If a user asks for http://cancer.webmd.com, the user's computer first asks for the cancer.webmd.com address. The webmd.com server finds cancer.webmd.com in its database and returns the "cancer.webmd.com has address 63.240.86.143" record.

If a user asks for http://crackedribs.webmd.com, the user's computer first asks for the crackedribs.webmd.com address. The webmd.com server checks its database and returns a negative response saying "crackedribs.webmd.com doesn't exist". The web browser, seeing this negative answer, displays an appropriate message for the user. Similarly, when mail-transfer agents see negative DNS answers, they bounce mail back to the sender.

Now imagine a DNSSEC-signed version of webmd.com. Any computer asking for the cancer.webmd.com address would be given not just the record "cancer.webmd.com has address 63.240.86.143" but also a signature on that record from the webmd.com administrator.

What happens if a computer asks for the crackedribs.webmd.com address? The server doesn't have a signature on crackedribs.webmd.com from the webmd.com administrator; the administrator has never seen the name crackedribs.webmd.com before.

The first drafts of the DNSSEC specification (in 1993) had no way to protect crackedribs.webmd.com. The server would send back an unsigned negative response saying "crackedribs.webmd.com doesn't exist". The client would accept this response. Of course, this also means that the client would accept forged negative responses such as "cancer.webmd.com doesn't exist", allowing attackers to sabotage domains that actually exist.

One can imagine having the client discard all negative responses. However, many Internet applications depend critically on negative responses. For example, mail-transfer agents check for DNS MX records first, and then fall back to A records in the (fairly common) case that MX records don't exist. Discarding MX-does-not-exist responses would be a disaster: mail to many sites would time out. (One could add special treatment for MX, SRV, etc., but this possibility does not seem to have been considered during the DNSSEC design.)

One can also imagine having the server sign negative responses upon request. However, DNSSEC was designed under the assumption that cryptography was much too slow for busy servers to handle online. This assumption forces all signatures to be precomputed.

What DNSSEC actually does, and has done since 1994, is precompute signatures on records such as "there are no names between cancer.webmd.com and data.webmd.com". Upon receiving a request for crackedribs.webmd.com, the server returns a signed record saying "there are no names between cancer.webmd.com and data.webmd.com".

The exact definition of "between" has changed several times in incompatible ways, attempting to juggle various concerns regarding subdomains, wildcards, server reliability, and server efficiency. The final "NSEC" definition is much too complicated to repeat here but does appear to be implementable, at least for servers whose databases are limited to static RFC 1034/1035 zone files.

What about DNSCurve?

Version