If you're running a DNS server, an attacker with access to your network can easily forge responses from that DNS server to other people. He can steal your incoming mail, for example, and replace your web pages.
An attacker from anywhere on the Internet, without access to the client network and without access to the server network, can also forge responses, although not so easily. In particular, he has to guess the query time, the DNS ID (16 bits), and the DNS query port (15-16 bits). The dnscache program uses a cryptographic generator for the ID and query port to make them extremely difficult to predict. However,
Larger cookies in the DNS protocol could make blind attacks practically impossible. (Caches could achieve a similar effect without protocol changes by repeating queries a bunch of times with different ports and IDs, at the expense of speed and reliability.) However, attackers with access to the network would still be able to forge DNS responses.
However, as of November 2002, Network Solutions simply isn't doing this. There is no Network Solutions key. There are no Network Solutions *.com signatures. There is no secure channel---in fact, no mechanism at all---for Network Solutions to collect *.com keys in the first place.
Even worse, the DNSSEC protocol is still undergoing massive changes. As Paul Vixie wrote on 2002.11.21:
We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?" ...It's impossible to know how many more flag days we'll have before it's safe to burn ROMs that marshall and unmarshall the DNSSEC related RR's, or follow chains trying to validate signatures. It sure isn't plain old SIG+KEY, and it sure isn't DS as currently specified. When will it be? We don't know. What has to happen before we will know? We don't know that either. ...
2535 is already dead and buried. There is no installed base. We're starting from scratch.
DNSSEC---for example, BIND 9's RFC 2535 implementation---has been falsely advertised for years as a software feature that you can install to protect your computer against DNS forgeries. In fact, installing DNSSEC does nothing to protect you, and it will continue to do nothing for the foreseeable future.
I'm not going to bother implementing DNSSEC until I see (1) a stable, sensible DNSSEC protocol and (2) a detailed, concrete, credible plan for central DNSSEC deployment.
In January 2001, an attacker fooled VeriSign, the parent company of Network Solutions, into signing a fake ``Microsoft Corporation'' ActiveX key. We're supposed to trust these people?
There's a different way to use public-key signatures to prevent forgeries. It's simpler and faster than DNSSEC, and it doesn't rely on a central authority.
The disadvantage is that it requires long host names, too long to remember. On the other hand, users seem to find computerized bookmarks a satisfactory solution to the problem of remembering long web addresses. As more and more business is carried out electronically, long host names will become less and less of a problem.
The idea is simply to give each computer a name that includes the computer's nym, a fingerprint of the computer's public key. Other computers then discard DNS records for these names if the records aren't accompanied by signatures under the corresponding public keys.
My top priority for djbdns is to support nym-based security.