BIND DNSSEC Validation

If you are searching for a DNSSEC validating DNS server, you can use BIND to do that. In fact, with a current version of BIND, e.g. version 9.10, the dnssec-validation is enabled by default. If you are already using BIND as a recursive or forwarding/caching server, you’re almost done. If not, this is a very basic installation guide for BIND with DNSSEC validation enabled and some notes on how to test it.

This blogpost is part of a series about DNSSEC. Refer to this list for all articles.

I am using a fresh Ubuntu 16.04 LTS installation with BIND 9.10.3-P4, that is:

The configuration files are stored in “/etc/bind/“. To allow DNS queries for the local clients, edit the options ( sudo nano named.conf.options ), add your subnets, e.g.:

and restart the server: sudo service bind9 restart.

DNSSEC by Default

The interesting part is that the DNSSEC validation is enabled by default. ;) The “dnssec-validation auto;” option is already present and the “dnssec-enable yes;” option is not needed, because its default is already “yes”. (See here: DNS BIND Security Statements.)

Furthermore, the directory option is already present, too:

That is, the managed keys are stored here: /var/cache/bind/managed-keys.bind .

Test with Dig

A basic test with dig against a DNSSEC secured domain will show the “ad” flag (authenticated data, see DNS Header Flags), in the header:

More relevant, a failure in a DNSSEC secured domain will result in a SERVERFAIL without an answer:

To test (!) the failure, the cd flag (check disabled) can be sent with dig, which reveals the answer, but of course with the cd flag again and not with the ad flag in the answer:


Online Test for Clients

More interesting for the clients is an online test whether DNSSEC validation works or not. I am using the one at If a client uses the just configured BIND server, the test looks like that:

DNSSEC Resolver Test ok

Congrats! You are now validating domain names.

Stats ‘n Cache

To view some statistics of BIND, execute the following shell command:

This appends the statistics into this file: /var/cache/bind/named.stats . Note the “+++ Statistics Dump +++ (1471872885)” beginning of each new dump, while the number in brackets is the unixtime. In my case, for example, this looks like that:

To view the current cache of BIND, run the following command:

This dumps the whole cache into this file: /var/cache/bind/named_dump.db .

It can be listed/grepped as normal, e.g.:

To delete (= flush) the cache, execute one of the following commands. The first one completely flushes the cache while the second only deletes a certain name:

Final notes: A much more detailed post about BIND as a caching server is here. And yes, I know that some security people don’t like the usage of BIND for a mere forwarding DNS server. The blog post about Unbound is coming soon. ;) Cheers.

Featured image “Daelim Motorrad Leichtkraftrad FOR SALE nur 9810km!” by naufragoenlasopa is licensed under CC BY-NC-ND 2.0.

2 thoughts on “BIND DNSSEC Validation

  1. hi,
    nice blog!

    as you use to the bind-tool “dig” you could also mention their tool “delv”?
    maybe you could explain why it’s usually imposible to ask the NS server of a domain for a DNSSEC signed answer.


    1. Yep, thx for the hint. I already did a blog post solely about “delv”:

      “maybe you could explain why it’s usually impossible to ask the NS server of a domain for a DNSSEC signed answer” –> by design, the authoritative name server *never* answers with the “ad” flag, but only with the “aa” flag. That is: it does *not* validate its own zones, because it knows it has the single source of truth concerning its own zones. No need to validate its own data. The authoritative server hands out the signed data (of course), but it does not the validation process.

      Does this help?


Leave a Reply

Your email address will not be published. Required fields are marked *