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.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState