BIND 9 and DNSSEC

The DNS of RFCs 1034 and 1035 is secure in the same way IPv4 is not very. You must be able to trust people, which you could on the Internet of 10 years ago, but now this has turned out to be a bit of a liability. On the other hand, if the root servers sign their query answers with known keys so you could check that the answers were unaltered and from a legitimate root server, it's a different situation. Additionally, if they also provide the public key of the nameserver to which they refer you, so that when, in turn, the answer comes back from that server you can verify that the answer is legitimate and unaltered, you have a new situation. You can trust DNS in a new way. Of course, this will still not stop people from entering bogus data into the DNS either by accident or ill will, so it will not really guard against all poisoning attacks. Spoofing, though, will become much more difficult (if not impossible), at least as long as the private key remains private and secret.

RFC 2535 specifies DNSSEC. BIND 8 starts to implement it and BIND 9 will complete it. DNSSEC is not in wide deployment on the Internet today, and it is not easy to find documentation of it beyond the RFCs. DNSSEC also faces some difficult issues of key management and contingency mechanisms when secret keys are compromised. The ARM documents how to perform some specific operations relating to DNSSEC, but assumes you are familiar with the concepts already. Expect more documentation in the future.

One thing that is readily understandable is TSIGs for zone transfers. Chapter 9, "Dynamic DNS," discusses TSIGs for dynamic DNS updates, and BIND 9 easily can be configured to use TSIGs for zone transfers, as well. In the case of zone transfers, TSIGs ensure that the slave accepts only zone transfers signed by the master. This is a great step forward in DNS security. If you run BIND 9, you absolutely should configure the keys necessary to enable this. See Chapter 16, "BIND 9," for how to set it up.