ICANN replaces secret DNSSEC keys

KSK rollover now under way

Last autumn, ICANN began the rollover of its Key Signing Keys. The rollover involves replacing the cryptographic key pair for the root zone: the basis of the entire DNSSEC infrastructure. The keys have to be changed periodically for security reasons. This'll be the first time that they've been rolled over since DNSSEC was introduced in 2010.

Rollover follows a carefully controlled procedure

ICANN's rollover is now in progress. A strictly defined and carefully controlled procedure has to be followed. That takes quite some time: about two years from start to finish. The rollover will be complete in August 2018. As long as nothing goes wrong, end users won't be aware of any change.

Important role for DNSSEC operators

At the local level, validating resolver operators have an important role to play in the rollover. If you operate a validating resolver, you need to add the new (public) key to your servers and later remove the old key from your system. Otherwise it won't be possible to validate the digital signatures of domain names under any of the top-level domains (TLDs). Then all internet domains will become unreachable for everyone relying on the resolver in question.

What you need to do in the short term

If you're a DNSSEC operator and you'd like to know more about the rollover and your part in it, we can help. Check out our special question and answer resource.

Key signing keys for .nl already replaced

We rolled over the Key Signing Keys for the .nl domain last year. Like the root zone rollover, it was the first since 2010. To assure the reliability of the DNSSEC infrastructure, a strict security protocol had to be followed. The old key pair was phased out of the .nl zone in summer 2016, and we are pleased to report that everything went without a hitch.

Frequently Asked Questions

The Key Signing Keys (KSKs) for the root zone are a cryptographic public/private key pair that plays a vital role in the DNSSEC security protocol. The key pair is the trusted starting point for DNSSEC validation, just as the root zone is the absolute starting point for looking up domain names in the DNS hierarchy.

Just as you start at the root zone when you look up a domain name in the DNS hierarchy, you start at the trusted root KSK when validating a DNSSEC signature. From there, you build a chain of digital signatures and public keys – the 'chain of trust' – to ultimately establish the authenticity of the relevant DNS information.

The rollover is the process that leads to ICANN deleting the existing KSK key pair that serves as the starting point for validation and as the trust anchor for the root zone, and replacing it with a new key pair ('KSK-2017'). This'll be the first such rollover since DNSSEC was introduced in 2010.

A back out or phase extension might be indefinite, or until such a time as the underlying problems had been studied and dealt with. ICANN would then implement the solutions in a new KSK rollover process.

The aim of a back out or phase extension would be to maintain the stability of the DNS, so the implications for end users would be minimal.

As long as nothing goes wrong, end users won't be aware of any change.

Internet access providers (IAPs), internet service providers (ISPs), registrars, hosting service providers, network operators and others who run validating resolvers need to have the new public KSK and install it as a trust anchor on their systems and devices.

  • ICANN is running a big campaign to make sure that everyone who uses the KSK key pair knows that it's changing.

  • A calendar is available on ICANN's website, with details of all the KSK rollover discussions that are taking place. There's also a web page with news and information about the rollover. And you can join a mailing list <link> for e-mail updates. ICANN's Twitter account tweets on the topic as well, under the hashtag #KeyRoll. So there are various ways of keeping abreast of developments.

  • SIDN, the operator of the .nl top-level domain, has developed its own communication plan to help the KSK rollover go smoothly in the Netherlands. These FAQs are part of that plan. Over the next few months, additional information will be made available on the Dutch DNSSEC knowledge platform. And SIDN will be highlighting the rollover in its newsletter and through its social media channels. Various knowledge partners and tie-ins will be involved as well.

  • SIDN has the following publications planned for this spring:

    • Practical advice on manual installation of the new public KSK as a trust anchor

    • A list of popular software packages for validating resolvers, saying whether each of them already supports, is going to support or isn't expected to support RFC 5011

For the autumn, the following publications are planned:

  • Practical advice on performing operational checks on software and systems to see whether RFC 5011 is implemented correctly, meaning that the trust anchor rollover can be handled automatically

  • Information about phasing out and deleting the old KSK key pair

Generally speaking, it isn't a good idea to keep the same cryptographic keys in use indefinitely. Like passwords, they need to be changed every so often for security reasons.

Replacing your keys on a reactive basis in an emergency could be seriously disruptive. So it makes more sense to replace them proactively as a precaution while everything is still running normally.

When DNSSEC was introduced in 2010, the US telecoms regulator NTIA – which was involved in the first phase of DNSSEC – ruled that the KSK key pair had to be replaced ('rolled over') at regular intervals. The operators of the root zone therefore drew up a plan for rolling over the keys five years after the introduction.

It's possible (or even likely) that the new trust anchor won't be installed on all systems and devices that perform DNSSEC validation. Worldwide, there are millions of resolving systems, serving maybe 750 million users. Another possibility is that some software won't be able to handle the update to the file containing the trust anchors. That pitfall is explained on IANA's website. If the problems were widespread, the root zone's operators could decide to roll back the changes in order to restore stability to the DNS system. That's known as the 'back out scenario'. ICANN could also prolong a phase in the rollover process to head off problems with the DNS system. That might be considered if, for example, new information came to light indicating that the next phase was going to trigger problems of one sort or another.

  • The KSK rollover process involves eight phases lasting a total of about two years. Each phase is linked to an official key ceremony. The individual phases are described in the timetable below.

  • The KSK key pair is used to digitally sign the root zone's DNSKEY Resource Record Set (RRset). The signatures are attached in the key ceremonies and then become part of the root zone.

  • Before the existing KSK key pair can be withdrawn, the new key pair has to be placed in the root zone alongside the old key pair. After a period when the two key pairs are operating side by side, the old key pair is removed from the root zone.

  • Phase A: key generation (October 2016):

    • The KSK-2017 key pair is generated at the first key management location.

  • Phase B: key replication (February 2017):

    • The KSK-2017 key pair is copied to the second key management location. The new KSK key pair is then officially ready for use.

  • Phase C: the primary DNS data is signed using the KSK-2017 key for use in phase D (May 2017):

    • The first requests for signing are performed.

  • Phase D: publication (August 2017):

    • ICANN publishes the public KSK-2017 key in the root zone.

    • The information in the root zone is signed with both the old KSK-2010 and the new KSK-2017 key.

  • Phase E: rollover (November 2017):

    • Only the new KSK-2017 key is still used to sign the root zone.

  • Phase F: withdrawal (February 2018):

    • ICANN deletes the old KSK-2010 key pair from the root zone.

  • Phase G: deletion 1 (May 2018):

    • ICANN deletes the old KSK-2010 key pair from the first key management location.

  • Phase H: deletion 2 (August 2018):

    • ICANN deletes the old KSK-2010 key pair from the second key management location.

  • Developers who are responsible for software that performs DNSSEC validation need to make sure that their products support RFC 5011. That's a standard for automatically importing the new public KSK from the root zone and installing it as a trust anchor.

  • We'll soon be publishing a list of popular software packages for validating resolvers, saying whether each of them already supports, is going to support or isn't expected to support RFC 5011.

  • For software that doesn't support RFC 5011 and devices on which RFC 5011 is disabled, a file containing the trust anchors is available from the IANA website. The file needs to be imported each time the resolver is started and whenever the KSKs in the root zone's DNSKEY RRset change.

  • Software developers and validating resolver operators can use the operational tests developed by ICANN. The tests let you check whether RFC 5011 is correctly implemented, meaning that the trust anchors will be automatically updated when the rollover goes through.


  • Monday 25 November 2019

    Internet security

    Does the arrival of DoH mean browsers should be regulated?


    New protocol gives browsers more power

    Read more
  • Friday 18 January 2019

    About SIDN

    IRMA wins ISOC.nl Internet Innovation Award 2019


    Praise for OpenINTEL as well

    Read more
  • Monday 23 July 2018

    Internet security

    Your bank's got a new log-in system? Watch out for scams!


    Cybercrooks take advantage of the wave of new tools and services

    Read more


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