Root zone rollover has implications for DNSSEC operators

19 January 2017

In autumn 2017, ICANN initiated the rollover of the (KSK) pair for the root zone. The rollover involves renewing (i.e. replacing) the root zone's cryptographic key pair, which underpins the entire DNSSEC infrastructure.

Renewing the key pair entails significant risk. Although it is very unlikely that anything will go wrong, an error could potentially render all internet domains (including non-signed domains) unreachable for all users and applications that rely on validating resolvers.

The situation is similar at the local level. Validating resolver operators need to first add the new (public) key to the trust anchors on their servers, and subsequently remove the old key from their systems. If an operator fails to act, it won't be possible to validate any digital signatures beneath the top-level domains (TLDs) in the root zone. Then all internet domains will become unreachable for everyone relying on the resolver in question.

RFC 5011 sets out a protocol for automatically installing the new (public) key as a trust anchor. The developers of the most widely used validating resolvers — BIND named, Unbound and OpenDNSSEC — all say that their software supports the protocol. The very dated Infoblox appliances don't support RFC 5011, meaning that Infoblox users face a fresh set of problems.

First rollover

The current operation involves the first rollover of the root key since the original root key was generated, installed and published in 2010. Although the rollover is now in full swing, there has been little publicity and few outward signs of activity, because it is a very carefully controlled and painstaking process.

The operational element of the rollover began properly last autumn, with the generation of a new KSK pair. The entire process will continue until March 2018, when the old key is due to be deleted from the root zone. However, the true duration of the administrative project is much greater. It started with the initial public consultation in 2013, and will not end until the old key pair is destroyed in August 2018.


The operational timetable is currently as follows:

  • 27 October 2016: new key pair generated

  • February 2017: new (public) key published on the IANA site

  • 11 July 2017: new (public) key published as DNSKEY record in the root zone

  • 11 October 2017: root zone signed using new key (actual rollover)

  • 11 January 2018: old (public) key withdrawn (digital signatures based on the old key pair cease to be valid)

  • 22 March 2018: old (public) key deleted from the root zone

  • August 2018: last remaining copy of the old key pair destroyed

New key pair

Although the new key pair has already been generated, the pair's public key has not yet been made available. Before being released, the keys have to be internally tested and audited, after which they can be copied to ICANN's second 'digital safe' (HSM). Only then can the public key first be published on the IANA website, and subsequently added to the root zone in the form of a DNSKEY record.

Validating resolver operators still have a little while to wait, therefore, until the new (public) key is actually published. Once it has been published, operators can add the key to their own systems as a trust anchor. That has to be done by 11 October 2017, after which the old key pair won't be used for signing. If an operator fails to act, it won't be possible to validate any digital signatures beneath the top-level domains (TLDs) in the root zone. Then all internet domains will become unreachable for everyone relying on the resolver in question.

Against that background, it is important that operators act now to ensure that the change is implemented in due course — even if the action consists of nothing more than setting a non-dismissible reminder. The rollover is, after all, a one-off event with major ramifications.


There are three ways of installing the new public key on a validating resolver as a trust anchor. First, there is the manual method. Once it becomes available next month, the key can be fetched from the IANA website and added to the resolver's configuration. At a later date, it will also be necessary to manually delete or disable the old key.

In some cases — e.g. with certain Linux distributions — the updates will be made automatically as part of the normal system updating process. First, the new trust anchor will be installed as part of a package update, and later the old trust anchor will be deleted in a similar way. Needless to say, that does depend on the relevant system update processes being run on a regular basis.

RFC 5011

In addition, a protocol has been developed that enables a validating resolver to autonomously fetch a new (public) key and install it as a trust anchor. RFC 5011 defines how a resolver can carry out a fully automated trust anchor rollover.

First, the new public key (in the form of a DNSKEY record) is obtained from an authoritative server for the root zone. The record has a digital signature anchored to the old, trusted key pair, so the resolver is able to confirm the record's authenticity using the usual DNSSEC functionality. A new flag — a Secure Entry Point (SEP) bit — is set in the DNSKEY record, so that the resolver knows that the key can be installed as a trust anchor.

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 compromised key pairs invalid, this existing functionality now serves to clear out expired key pairs.

The RFC also describes various scenarios in detail, explaining how each should be dealt with and setting out the timing requirements for ensuring the reliability of the process.

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.


The developers of various validating resolvers, including BIND named, Unbound and OpenDNSSEC, have indicated that their products support RFC 5011.

Unfortunately, however, Infoblox appliances do not support the protocol. We have already reported that the Infoblox DNSSEC implementation is seriously outdated, and the lack of RFC 5011 support represents a further problem in that regard. Infoblox appliances are used mainly by large organisations such as government agencies and banks, on the assumption that they represent a turnkey solution.


Even if validating resolver software is claimed to support RFC 5011, we recommend checking that everything is in order. After all, there has never been a root key rollover before, and the risks for end users are considerable. Validating resolver operators are therefore advised to closely monitor and double-check the (automatic) installation of the new (public) key as a trust anchor. Automated installation is possible from 11 June, when the new key is published in the root zone in the form of a DNSKEY record.

However, manual installation of the new trust anchor will be possible from next month. That is when the new (public) key is first published on IANA's website.

Finally, the old trust anchor can be deleted on or after 11 January 2018, but no later than 22 March 2018.


  • Monday 15 April 2019

    About SIDN

    We have a new house style!

    A new logo, a fresh look and new pay-off.

    Read more
  • Monday 26 March 2018

    Internet security

    Everyone should have access to a secure connection


    Let’s Connect! is an open-source VPN solution

    Read more
  • Thursday 14 March 2019

    .nl domain name

    SIDN analyses


    Van een startkapitaal van € 2.000,- naar een omzet van € 200 miljoen

    Read more


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