Securing DNS and BIND

Decreasing the vulnerability of your DNS server is largely a matter of staying current and private.
Advanced BIND Security: TSIGs

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:

  1. create a key for the zone

  2. on each server, create a key{} entry in named.conf containing the key

  3. on each server, create a server{} entry in named.conf for the other server which references the key declared in step (2).

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!

Conclusion

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

email: mick@visi.com

Mick Bauer (mick@visi.com) is security practice lead at the Minneapolis bureau of ENRGI, a network engineering and consulting firm. He's been a Linux devotee since 1995 and an OpenBSD zealot since 1997, taking particular pleasure in getting these cutting-edge operating systems to run on obsolete junk. Mick welcomes questions, comments and greetings.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix