The Domain Name System (DNS) is built on a simple expectation: When you look up a domain name, you get the right answer. Part of ensuring that reality is through an array of security measures that allows software to validate DNS data using security protections known as DNS Security Extensions (DNSSEC). They work by ensuring that all the component pieces of a domain name are cryptographically verifiable through a chain of signatures, each of which can be validated through a chain that starts with the root zone key signing key (KSK). This cryptographic key is operated by us through the IANA functions we manage.
As with all security systems, from time to time the keys need to be replaced. When the key at the top of the DNS hierarchy – known as the “trust anchor” – needs to change, it is a process known as a root zone KSK rollover. This change needs to be carefully coordinated to preserve the security, stability, and ongoing unified operation of the DNS.
Unlike many updates to Internet infrastructure, a KSK rollover does not add new functionality. Instead, it keeps a critical piece of the system up to date with best cryptographic practices. Cryptographic keys that remain in use for too long can become a liability. Updating the KSK helps ensure that the root zone continues to rely on strong cryptographic material; a way of staying ahead of that risk is by periodically changing keys, rather than reacting to news that a key has become too weak to use.
What makes the rollover notable is not the act of generating a new key, but how it is introduced. The DNS is global and highly distributed, with validating resolvers operated by a wide range of organizations.
As the KSK acts as the trust anchor for DNSSEC validation, when DNS resolver software needs to check whether DNS data is authentic, it needs to check against this specific key. Because of that central role, any change has to be introduced carefully. A sudden switch would risk disrupting validation for systems that are not prepared to recognize the new trust anchor, because resolvers that haven’t updated fail validation. To guard against this, the rollover is a coordinated effort over a long period of time to ensure widespread adoption.
Unlike many updates to Internet infrastructure, a KSK rollover does not add new functionality. Instead, it keeps a critical piece of the system up to date with best cryptographic practices. Cryptographic keys that remain in use for too long can become a liability. Updating the KSK helps ensure that the root zone continues to rely on strong cryptographic material; a way of staying ahead of that risk is by periodically changing keys, rather than reacting to news that a key has become too weak to use.
What makes the rollover notable is not the act of generating a new key, but how it is introduced. The DNS is global and highly distributed, with validating resolvers operated by a wide range of organizations.
As the KSK acts as the trust anchor for DNSSEC validation, when DNS resolver software needs to check whether DNS data is authentic, it needs to check against this specific key. Because of that central role, any change has to be introduced carefully. A sudden switch would risk disrupting validation for systems that are not prepared to recognize the new trust anchor, because resolvers that haven’t updated fail validation. To guard against this, the rollover is a coordinated effort over a long period of time to ensure widespread adoption.
A new KSK is generated and published well before it is put into use. This gives operators time to update their systems. During the transition, both the existing and new keys are trusted, allowing for a gradual shift rather than a hard cutover. Only once there is confidence that the new key has been widely accepted does the system complete the transition and retire the previous one.
That pacing is deliberate. Even a small number of outdated resolvers can have outsized effects, particularly if they sit within large networks. In those cases, users may encounter resolution failures despite the DNS itself functioning normally. Avoiding that outcome depends less on the mechanics of the rollover and more on coordination across the ecosystem.
This is where ICANN plays its role. Through the IANA functions, ICANN manages the DNS root and the associated trust anchor. The KSK rollover is part of that ongoing work. It combines careful operational planning with outreach to ensure that those running validating resolvers are aware of the change and have time to prepare.
KSK ceremonies are one piece of this broader picture. They provide a controlled environment for generating and safeguarding the cryptographic material used in the rollover. While those ceremonies often draw attention, the more consequential work happens over the longer transition period, as the new key is introduced across the global DNS.
For users on the Internet, if everything goes according to plan, the rollover will pass without notice. There should be no visible change, no interruption, and no reason for most people to think about it at all.
For the operators of infrastructure directly related to how DNSSEC works, a rollover is a time to be vigilant and to monitor systems, and to make sure the largely automated update mechanisms are operating as intended. A small investment of time now will guard against potential impacts to their infrastructure if it turns out their software or configuration is out of date when the rollover becomes effective.
The KSK rollover may not be a dramatic event, but it is an extremely important one. It reflects the ongoing work required to keep the DNS reliable through careful planning, technical discipline, and coordination across the Internet community.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
