---
title: "9.16 DNSSEC validation automatic trust anchor management"
slug: "916-dnssec-validation-automatic-trust-anchor-management"
description: "Here are some tips on managing trust anchors, the public keys associated with the private keys used to sign a zone."
updated: 2021-10-04T17:59:43Z
published: 2021-10-04T17:59:43Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

# 9.16 DNSSEC validation automatic trust anchor management

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](https://tools.ietf.org/html/rfc5011) 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](https://bind9.readthedocs.io/en/v9_16_21/advanced.html#dnssec)

[The BIND 9 DNSSEC guide](https://bind9.readthedocs.io/en/v9_16_21/dnssec-guide.html)

[DNSSEC validation - how can I tell if my server is doing it?](/v1/docs/aa-01547)