HOWTO turn BIND into a Validating Resolver

Written by Rick van Rein in category: Procedures, Security, Technical, Users
Time to pin down the safety of DNS

WikiMedia Commons

This instruction explains how to setup DNSSEC validation with the BIND resolver for DNS. A companion article on Unbound also exists. Note that Unbound has been written for security from the ground up, and carries less history than BIND.

Install. We used BIND 9.7.1-P2 on Debian Linux. Variations should work; there even is a prebuilt binary for Windows. Aside from the general practice to always run the latest BIND for security reasons, it is specifically good to use 9.7 and beyond because it can keep up to date with root zone keys as they rollover.

The best option on Linux is to build it from source code (although pre-built packages are also available for several distributions; recent versions of BIND are also included in the ports tree of several BSD distributions). This can be obtained from

The build is straightforward enough; by default it installs everything under /usr/local which we will assume because you may not like overriding any old setup in /etc and /usr. So you would do:

make install

Configure trust. First, find the the trust anchor for the root zone and verify that it is reliable. To obtain the root zone’s DNSKEY records, simply do:

dig . dnskey

.			71410	IN	DNSKEY	256 3 8 AwEAAb...
.			71410	IN	DNSKEY	257 3 8 AwEAAagA...

You need the one with value 257 behind the DNSKEY record type (the second key in the example above). The value indicates that this is a Secure Entry Point for the zone, or as we usually call it, the Key Signing Key. Keys with 256 are subordinates, known as Zone Signing Keys.

Save the key definition to a temporary file and run dnssec-dsfromkey on it to hash it into a DS record:

/usr/local/sbin/dnssec-dsfromkey -2 -f /path/to/keyfile .

Use the outcome of this command to verify the reliability of the selected DNSKEY. If it is reliable, edit the configfile for BIND in /usr/local/etc/named.conf. Aside from your usual configuration details for a resolving cache, you will have to
create a section and fill it with the DNSKEY fields, like this:

managed-keys {
        "." initial-key 257 3 8 "AwEAAagAIKlVZrp...";

Also set the following in the options configuration section:

dnssec-enable yes;
dnssec-validation yes;

You probably want to ensure that the older DLV setup options dlv-lookaside are disabled, unless you have decided to mix this alternate channel with the trust paths for the root zone. Also check that any other trusted-keys are gone, as should be the case in a pristine setup of BIND. If you have been relying on ITAR in the past, this is the time to clean up that temporary trusted key.

Run. Now fire up BIND:

/usr/local/sbin/named -c /usr/local/etc/named.conf

If no errors show up in syslog and the daemon starts to listen to port 53, it should perform as usual, except that it does now
actively seek DNSSEC approval on domains that are known to carry a chain of signatures from the root zone down.

The first sign that this is working is that BIND creates a file named managed-keys.bind holding the Key Signing Key currently in use by the root zone.

A successful reply would include an Authenticated Data or AD flag, which serves as an assurance to stub resolvers that are not DNSSEC-aware, in this case human eyeballs. A small session showing this flag would look like:

janneke$ dig @localhost +dnssec br ds
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

Why query for DS records, you wonder? Like any parent/child transition in DNS, the TLDs in the root zone are present in both parent and child name servers. The DS record is the only one that is normally only present in the parent, so this answer is certain to come from the parent, which is the root zone because we are asking for a TLD name. Further down, things start depending on more complex constructions. More on that later!

And that’s all, you’re done. The only thing you may want to ensure is that the new signing keys are pulled in when the root zone rolls over its keys, and specifically, its Key Signing Key. The procedure should be automatic with the setup given
here, but it’s probably better to be safe than sorry.

2 Comments to “HOWTO turn BIND into a Validating Resolver”

  1. Mudassir says:

    (1) How can i change default resolver to some other server and verify that a nsloookup fails on the client?
    (2) How can i revoke the DNSSEC certificate and verify that it fails ?
    (3) How can i expire the DNSSEC certificate and verify that it fails ?
    Also, why we have a reliance on an external root (…since we are using this internally only?
    (4) How can i verify that a valid, non-expired certificate from a foreign domain properly fails ?
    (5) How client should only accept traffic from DNSSEC aware ?

  2. admin says:

    Hi Mudassir,

    The post you are commenting to is quite old and may be outdated; please have a look at our recent publication on setting up a validating resolver:

    Best regards,

    Roland van Rijswijk