Paranoid Penguin - DNS Cache Poisoning, Part II: DNSSEC Validation

Configure your DNS server to check zone signatures using DNSSEC.
Setting Up DNSSEC Validation

Back on your caching nameserver, all you need to do to add DNSSEC validation is add three lines in the options{} section of your /etc/bind/named.conf.options file, plus a new managed-keys{} section, as shown in Listing 3.

The first two new lines in Listing 3, dnssec-enable yes; and dnssec-validation yes;, enable DNSSEC on your caching nameserver. This is actually a redundant setting, because “yes” is the default value for both these settings in BIND versions 9.5 and later, but it doesn't hurt to specify them.

The third new line, dnssec-lookaside auto;, tells BIND/named to use DLV automatically any time it can't validate a complete chain of trust from a given Resource Record all the way from root (.) downward. See the DNSSEC Overview section earlier in this article if you've forgotten how DLV works.

As I mentioned in that section, recent versions of BIND are preconfigured to find's DLV repositories. All you have to do to take advantage of this is set “dnssec-lookaside” to “auto”, and BIND will do the rest. As more and more TLDs are signed, this feature will become less important.

And, that brings me to the last new element in the named.conf.options file: the managed-keys{} section. This specifies a key for the DNS “root” domain, which is the top of any chain of DNSSEC trust.

You don't necessarily need to specify any keys “lower” in the DNS hierarchy than root; if you start out knowing the root key, you can trust signed replies from root nameservers. That trust flows downward to signed data from TLDs (.gov, .us, .net and so on) and so forth. “Gaps” in the downward chain of validation hopefully will be handled by DLV.

For heaven's sake, do not simply copy Listing 3's key entry for “.” verbatim! Tony Finch has written a quick-and-easy procedure on checking and validating the (initial) root certificate (see Resources). Summarized, this procedure consists of the following steps.

1) Use the following dig command to obtain the current root certificate and save it to the file root-dnskey:

bash-$ dig +multi +noall +answer DNSKEY . >root-dnskey

2) Create a hash of this certificate and save it to the file root-ds with this command:

bash-$ $ dnssec-dsfromkey -f root-dnskey . >root-ds

3) Pull the official root certificate's hash from, and compare it to the root-ds file you just created. For extra paranoia, you can use PGP to check the signature of root-anchors.xml (see Tony Finch's article).

4) If the hashes match, copy the key (the long one, number 257) from root-dnskey into your managed-keys statement, as shown in Listing 3. The first line of this block (after the managed-keys { line) should be the same as in Listing 3.

As with your previous changes, after you save named.conf.options, you should check it with named-checkconf, and then load it with rndc reload.

Finally, to test DNSSEC validation, test some known-signed record, such as, using dig. Be sure to use the +dnssec flag, like this:

mick@someotherhost:/home/mick$ dig @ 
 ↪ +dnssec

If everything is working, dig's output should indicate that the “ad” (authenticated data) flag is set. Listing 4 shows the first part of what a successful reply to our example dig command would look like. Note the line that begins ;; flags: qr rd ra ad;.


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot