Automatic installation of new DNSSEC trust anchor

Most software for DNSSEC-validating resolvers now supports RFC 5011. Any resolver running such software can therefore automatically install the new public root KSK as a trust anchor.

Although RFC 5011 is designed so that (root) KSK rollovers can take place without the system administrator's intervention, it's important to check that your resolver's current installation/configuration does actually support automatic trust anchor installation. If a validating resolver doesn't have the new trust anchor installed by 11 October 2017, all internet domains will become unreachable for any user or application relying on that resolver.

In an earlier articlewe explained the different ways that validating resolver operators can install the new trust anchor on their systems and provided guidance tailored to the various resolver software packages.

In this article, we take a look at RFC 5011 and tell you what support the most popular resolver software products provide. In a follow-up piece, we'll explain how you can check that the new trust anchor is installed and working properly.

RFC 5011

RFC 5011 is a protocol that lets a validating resolver implement the whole rollover process itself. First, the new public key (in the form of a DNSKEY record) is obtained from an authoritative server for the root zone (or another trust point). The record has a digital signature based on the old, trusted key pair, so the resolver is able to confirm the record's authenticity using the usual DNSSEC functionality. The SEP bit (Secure Entry Point bit; see RFC 3757) in the DNSKEY record tells the resolver that the KSK is valid.

At a later stage, the old public key can be removed from the list of trust anchors by setting the DNSKEY record's REVOKE flag. In other words, as well as being used to declare insecure key pairs invalid, this existing functionality now serves to clear out expired keys.

Because the method depends entirely on a trusted public key being present on the resolver side, it will work only with systems on which a trust anchor is already installed. Most resolver software developers therefore provide the current trust anchors hard-coded into their products as a matter of course.


The new key (KSK-2017) was published in the root zone on 11 July. You can request the current public keys from the root zone as follows:

dig +multiline . DNSKEY

The following output will then be obtained:

  .    13775 IN DNSKEY  257 3 8 (
           ) ; KSK; alg = RSASHA256; key id = 19036
  .    13775 IN DNSKEY  257 3 8 (
           ) ; KSK; alg = RSASHA256; key id = 20326
  .    13775 IN DNSKEY  256 3 8 (
           ) ; ZSK; alg = RSASHA256; key id = 15768

The key with key ID 20326 is the new public KSK. The value 257 (set SEP-bit) tells you that this is a valid KSK.


For security reasons, RFC 5011 states that a new public KSK must not be added to the trust anchors for at least thirty days (the hold-down period). During that period, a resolver has to check at intervals not exceeding two weeks whether the new key is still present. Any resolver that has obtained the key as described will therefore activate it as a trust anchor in the period 10 to 24 August.


The most popular resolver software packages are listed below, with details of their RFC 5011 support status.

BIND named

  • Supports RFC 5011 from version 9.7.0 ('managed-keys')

  • Manual installation from version 9.6.2 ('trusted-keys'), the first implementation of DNSSEC validation in BIND


  • Supports RFC 5011 from version 1.4.0 (managed keys in 'auto-trust-anchor-file')

  • Manual installation as static trust anchor for older versions (using 'unbound-anchor')

  • KSK-2017 trust anchor supplied with software from version 1.6.1

  • Release 1.6.5¬†fixes a problem with Unbound installations made between 11 September and 11 October of this year; operators who install Unbound in the near future should therefore use this latest version

PowerDNS Recursor

  • Supports validation only from version 4.0; doesn't yet support RFC 5011

  • KSK-2017 trust anchor supplied with software from version 4.0.5

  • Upgrade or manual installation using the Lua interface


Windows DNS Server

Knot DNS Resolver


  • Doesn't support RFC 5011

  • KSK-2017 trust anchor supplied with software from version 2.77

  • Manual installation required (from version 2.69, the first implementation of DNSSEC, using trust-anchors.conf)

  • Developer Simon Kelley says that versions older than 2.76 should no longer be used anyway, due to bugs in the validation element

Next step: testing

The list presented above, together with the information we previously provided about manual trust anchor updating, gives you a good basis for preparing your resolvers for the actual rollover (scheduled for this autumn). It's important to recognise that, in practice, an existing installation may differ considerably from those we describe. For example, the maintainer of an OS distribution may have added KSK-2017 to 'their' packages as a trust anchor. There is also the possibility of an installation running a new version of the resolver software, but with an outdated configuration.

The next step is to test whether everything is working as it should. That topic will be covered in a follow-up article, which we'll publish once all resolvers that support RFC 5011 should have activated the new trust anchor.


  • Tuesday 16 July 2019

    SIDN Labs

    TimeNL: the transparent new NTP service from SIDN Labs


    The importance of accurate time measurement and synchronisation

    Read more
  • Tuesday 24 September 2019

    SIDN Labs

    Experimenting with new internet infrastructures: SCION


    SIDN Labs connected to SCIONLab

    Read more
  • Tuesday 5 February 2019

    About SIDN

    Netherlands falls further behind on IPv6


    Countries everywhere are overtaking the Dutch

    Read more


Your browser is too old to optimally experience this website. Upgrade your browser to improve your experience.