Securing DNS and BIND

Whew! We've looked at BIND security from several important angles, but we haven't even mentioned cryptographic controls. Actually, the Secure DNS protocol (“DNSSEC”, described in RFC 2535) merits an article of its own. This set of extensions to DNS provides a means of cryptographically signing zone-transfer and query transactions, including the secure exchange of all necessary key data. Since DNSSEC hasn't yet been widely implemented (and in fact isn't even fully supported in BIND v.8x), we'll limit our discussion of it to the use of Transaction Signatures (TSIGs).

Suppose you wish to sign all zone transfers between the zone's master and a slave. You would do the following:

Step one is most easily done with BIND's dnskeygen command. To create a 512-bit signing key that can be used by both master and slave, type dnskeygen -H 512 -h -n <desired_keyname>. The output will be saved in two files named something like Kdesired_keyname.+157+00000.key and Kdesired_keyname.+157+00000.private. In this case, the key-string in both files should be identical; it will look something like “ff2342AGFASsdfsa55BSopiue/-2342LKJDJlkjVVVvfjweovzp2OIPOTXUEdss2jsdfAAlskj==”.

Steps two and three consist of creating entries similar to the following in named.conf on each server (substituting “desired_keyname” below with whatever you wish to name the key—this string must be the same on both servers!):

key desired_keyname {
        algorithm hmac-md5;
        secret "<insert key-string from either keyfile here>";
}
server <IP address of other server> {
        transfer-format many-answers;
        # (send responses in batches rather than singly)
        keys { desired_keyname; };
};

Note that key{} statements must always precede any other statements (e.g., server{} statements) that refer to them. A logical place to put key-server statements is between options{} and zone statements.

Now all you need to do is restart named (via a kill -HUP or ndc restart) on both servers. Voilà! You are now on the cutting edge of DNS security!

The guidelines and techniques we've covered here should give you a good start on securing your DNS server(s). For a more in-depth understanding of these techniques, I strongly recommend BIND's on-line version of its Operators' Guide (included in most binary distributions, or available separately from http://www.isc.org/). This is among the most useful documents provided in any OSS package. Another excellent source of BIND security information is Liu's “DNS Security” slide show (available from him in PDF format—see below).

Equally important, every BIND user should subscribe to at least one security-advisory e-mail list. CERT is my personal favorite, since it's timely enough to be useful but low-volume enough to not be a nuisance. And at your earliest convenience, you should look up and read the CERT advisories listed below—understanding the threats is an essential part of good security.

Resources