Written by I)ruid

Configuring DNSSEC in BIND

DNSSEC, which I mentioned in my previous post about mitigation for Kaminsky’s recent DNS cache poisoning flaw, are the SECurity extensions for the Domain Name System (DNS). It essentially adds cryptography to DNS, allowing authoritative nameservers to cryptographically sign their zones and resource records, which in turn allows caching/recursive nameservers to verify them. This prevents attacks against the recent cache poisoning flaw by allowing the nameserver under attack to verify that a record it receives is valid by checking the cryptographic signature against the zone’s public key. Theoretically, an attacker would not be able to forge this signature unless the zone’s keys have been compromised.

I’ve spent a bit of time over the past few days researching DNSSEC, as it’s been standardized for nearly a decade now but there hasn’t been much adoption. It’s most likely The Best™ solution for the recent vulnerability, but I’ve heard time and again that it’s too complicated and has too many controversial issues surrounding it which is why many admins haven’t adopted it into their infrastructure and still don’t plan to.

During this research, I’ve configured all of my nameservers to use  DNSSEC, both authoritative and caching/recursive. While it is a bit of a pain on the authoritative side having to deal with signature expiration, key rotation, proving your identity and ownership of the zone to a domain lookaside verification (DLV) registry and providing your DLV records, etc., configuration for caching/recursive nameservers was relatively straight-forward and simple. While this will obviously only protect you from accepting spoofed, poisoned cache entries for records within zones using DNSSEC, why would you not want to at least verify signatures for those zones that do provide them?

1. DNSSEC for Caching/Recursive Nameservers

The first thing you’ll want to do is enable DNSSEC in your named.conf file:

options {
     dnssec-enable yes;
     dnssec-validation yes;
};

Validation is centered around a chain-of-trust model, of which each chain ends at an authoritative trust-anchor under which you want to validate. For example, if you want to validate everything under *.dustintrammell.com., you’d need a trust anchor for “dustintrammell.com.”, “.com”, or “.”. Because not all domains use DNSSEC, including some of the Top Level Domains (TLDs) like .com, .net, .us, etc., Internet Systems Consortium, Inc. provides a DLV registry. To configure use of their DLV registry service, you’ll want to add this to your named.conf file:

trusted-keys {
     dlv.isc.org. 257 3 5 “BEA[...]uDB”;
};
options {
     dnssec-lookaside . trust-anchor dlv.isc.org.;
};

You can retrieve the keys that need to be placed in the trusted-keys section by digging for DNSKEY records:

$ dig +dnssec dlv.isc.org. dnskey
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.4.2-P1 <<>> dlv.isc.org. dnskey
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46338
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dlv.isc.org.                   IN      DNSKEY

;; ANSWER SECTION:
dlv.isc.org.            4319    IN      DNSKEY  257 3 5 BEA[...]uDB
dlv.isc.org.            4319    IN      DNSKEY  256 3 5 BEA[...]Q==
dlv.isc.org.            4319    IN      DNSKEY  256 3 5 BEA[...]w==

Finally, you’ll want to restart your nameserver or reload it’s config for the configuration changes to take effect, and that’s pretty much it. Now the nameserver has DNSSEC enabled, is configured to validate, and knows where to go to look for keys that it doesn’t have a trust-anchor for.

2. DNSSEC for Authoritative Nameservers

This is, as previously mentioned, much more complicated. The basic steps are to generate keys for all of your zones, add the public keys to those zones, sign the zones, and provide the DLV information to the DLV registry. Once you understand it, all but that last task is scriptable.  Further, you need to resign your zones at least once every 30 days, and rotate your keys every once in a while, which is also scriptable.

I’m not going to go into all of that detail here however, or this article would be ridiculously long. Instead, I’m going to refer you to the wonderful slide deck by Alan Clegg from ISC that walked me through the entire process and really clued me into DNSSEC.

Leave a Reply