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;,
Listing 3. DNSSEC-Enabled named.conf.local
acl mynetworks { 192.168.100.0/24; 10.10.0.0/16; };
options {
directory "/var/cache/bind"; allow-query { mynetworks; };
auth-nxdomain no; # conform to RFC1035 listen-on-v6 { none; }; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; }; managed-keys { "." initial-key 257 3 8 " AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= "; };
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 isc.org’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 https://data.iana.org/root-anchors/root-anchors.xml, 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 www.isc.org, using dig. Be sure to use the +dnssec flag, like this:
mick@someotherhost:/home/mick$ dig @192.168.100.253
¯www.isc.org +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;.
Conclusion
And with that, your nameserver is successfully validating signed zone data! For now, I wish you thanks and goodbye. As I seem to do every couple years, I’m going to take a hiatus for a few months. I do plan on resuming the Paranoid Penguin after that, however, refreshed and renewed for your reading pleasure.
Until then, take care of yourself and especially
your Linux systems!I
Mick Bauer ([email protected]) is Network Security Architect for one of the US’s largest banks. He is the author of the O’Reilly book Linux Server Security, 2nd edition (formerly called Building Secure Servers With Linux), an occasional presenter at information security conferences and composer of the “Network Engineering Polka”.
PARANOID PENGUIN
Listing 4. dig Output for Successful DNSSEC Validation
; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.100.253 www.isc.org +dnssec ; (1 server found)
;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62704
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13
Resources
DNSSEC—the DNS Security Extensions—Protocol Home Page: www.dnssec.net
Alan Clegg’s “DNSSEC—Living and Loving Life after Kaminsky; Or: How I overcame my fear and signed my zones.” Presentation to REN-ISAC on 10-30-2008: www.ren-isac.net/techburst/hardcopy/ ren-isac_techburst_20081030_clegg_dnssec.pdf
Geoff Huston’s “A Fundamental Look at DNSSEC, Deployment, and DNS Security Extensions”: www.circleid.com/posts/ dnssec_deployment_and_dns_security_extensions
Ubuntu 10.10 Server Guide: “Chapter 7. Domain Name System (DNS)”: https://help.ubuntu.com/10.10/serverguide/C/dns.html BIND 9.7 Administrator’s Reference Manual (ARM):
ftp.isc.org/isc/bind9/cur/9.7/doc/arm/Bv9ARM.pdf
Tony Finch’s “How to set up DNSSEC validation with BIND-9.7”: fanf.livejournal.com/107310.html