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;.


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

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