UNIX System Administration Handbook - Evi Nemeth [280]
The material in this section describes DNSSEC as of BIND v9.0.0 (July, 2000). Judging from the significant changes that occurred during the beta cycle, this information may not be correct for long. As always, consult your manuals, the documentation that comes with BIND, and the O’Reilly DNS book for the exact details. That said, lets look at some potential problems with the current DNSSEC design.
DNSSEC is at odds with the notions of caching and forwarders. DNSSEC assumes that queries contact the root zone first and then follow referrals down the domain chain to get an answer. Each signed zone signs its children’s keys, and the chain of trust is unbroken and verifiable. When you use a forwarder, however, the initial query is diverted from the root zone and sent to your forwarding server for processing. A caching server that is querying through a forwarder will recheck signatures, so responses are guaranteed to be secure. But, for the query to succeed, the forwarder must be capable of returning all the SIGs and KEYs needed for the signature checking. Non-DNSSEC servers don’t know to do this, and the RFCs ignore the whole issue of forwarding.
BIND 9 implements some extra features beyond those required by RFC2535 so that a BIND 9 caching server can use DNSSEC through a BIND 9 forwarder. If you are using forwarders and want to use DNSSEC, you might have to run BIND 9 throughout your site.
Unfortunately, those busy sites that use forwarders and caching are probably the sites most interested in DNSSEC. Alas, the standards writers didn’t quite think through all of the implications for the other parts of the DNS system.
DNSSEC also relies on the existence of a public key infrastructure that isn’t quite a reality yet. There is no smooth way to get the parent to sign a child’s keys; we cannot send mail to the hostmaster@com and get signed keys back. In the next few years we should start to see DNSSEC deployed, probably beginning with signed versions of the root zones. Sysadmins need to keep an eye on DNSSEC development, but it’s too early (Summer, 2000) to really worry about DNSSEC for now.
Transaction signatures (TSIG/TKEY) use less CPU time and network bandwidth than does public key authentication, but they guarantee only that you know where your responses came from, not that the responses are correct. A combination of a TSIG relationship with a server known to do full DNSSEC might provide a reasonable degree of security. It is not possible to have a TSIG relationship with every server you might ever want to talk to, since TSIG relationships must be manually configured.
Microsoft bad, UNIX good
Windows 2000 uses SRV resource records to discover everything: name servers, printers, filesystems, and so forth. They have followed the IETF specs in their implementation of SRV records, but the way that they insert the records into DNS by using a secure dynamic update is nonstandard. Microsoft uses a variation of transaction signatures called GSS-TSIG that is also based on a shared secret. The shared secret is obtained through Kerberos from the Kerberos KDC (Key Distribution Center). At the moment, Microsoft’s implementation is not compatible with the open source version of Kerberos 5. (Hmm ... Embrace, extend, exterminate.)
If you want to run Win2K and use SRV records, you’ll have to nuke your existing Kerberos realm and run a Win2K Kerberos server on your networks. For some sites with a rich Kerberos infrastructure, this problem is a showstopper. Perhaps Microsoft will document their extensions.
About a week after Win2K was released, the query load on the DNS root servers increased significantly. A bit of digging revealed that misconfigured Win2K boxes were trying to dynamically update the root or top-level zones. The number of UDP queries to the A root server more than doubled as a result. To