9.16 DNSSEC validation automatic trust anchor management
  • 04 Oct 2021
  • 2 Minutes to read
  • Contributors
  • Dark
  • PDF

9.16 DNSSEC validation automatic trust anchor management

  • Dark
  • PDF

Article summary

When upgrading to BIND 9.16 from 9.11 - the two current active releases - you might wonder what this log message means:

named[xxx]: dnssec: warning: managed-keys-zone: Initializing automatic trust anchor management for zone '.'; DNSKEY ID 20326 is now trusted, waiving the normal 30-day waiting period

As the message suggests, it is to do with trust anchors for DNSSEC. But what is automatic management and why am I only seeing it now?

Trust anchors are the public keys associated with the private keys used to sign a zone: the public keys are held as a DNSKEY RRset in the zone. If DNSSEC validation is required on a recursive server, then when BIND starts up it needs to establish a trust anchor for the root zone, which can be done in one of two ways:

  1. A trust-anchors statement can be added into named.conf manually. For this you will need to obtain a guaranteed genuine version of the root key because this becomes the basis on which all validation is done. Having done this, in named.conf set the parameter dnssec-validation to yes, which was the default before BIND 9.13.
  2. In named.conf set the parameter dnssec-validation to auto, which is the new default since BIND 9.13. This causes BIND to use the procedures defined in RFC 5011 to obtain the key automatically. It is this process that generates the warning message highlighted above.

The default was changed from yes to auto in 9.13 to bring BIND more in line with global standards, making it a fully validating resolver 'out of the box'.

The value auto may not be appropriate in all cases: for example for an internal-only recursive server that cannot obtain the root DNSKEY RRset for itself. In this case, set dnssec-validation to yes (the old default) and add trust-anchors manually.

With manually added trust anchors you have the choice of defining them as a static-key or an initial-key.

static-key is appropriate for a server that cannot reach the Internet, e.g. an internal resolver, as mentioned above. This key is always trusted and needs to be maintained by hand when the value of the public key in the Internet changes.

initial-key is trusted once, at boot time. After that, automatic key updates occur using the same mechanism as setting dnssec-validation to auto and therefore requires that the server has Internet access. In practice, using auto would be the easier choice.

Even if a BIND server is built with the intention of it being authoritative-only (i.e. configuring recursion no in options) it will still perform automatic trust anchor updates by default. To disable DNSSEC validation completely, set dnssec-validation to no. This allows it to be changed at a later date, if required.

If you wish to build BIND yourself from source, the default can be changed from auto back to yes at build time by using the configure option --disable-auto-validation.

Further reading material on the subject of DNSSEC can be found in the following resources:

The BIND 9 ARM chapter on DNSSEC

The BIND 9 DNSSEC guide

DNSSEC validation - how can I tell if my server is doing it?