Negative DNS forgery

The webmd.com DNS database contains various records such as
"data.webmd.com has address 63.240.86.26"
and
"cancer.webmd.com has address 63.240.86.143".

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?

DNSCurve eliminates negative forgeries
in exactly the same way that it eliminates positive forgeries.
All responses are encrypted and authenticated when they enter the network,
using state-of-the-art cryptography that is fast enough to handle online.
Forged packets, whether positive or negative, are quickly recognized and discarded.