Root zone KSK rollover nears October 2026 completion

The cryptographic key securing the DNS root zone is set to change for only the second time in history, with a hard cutover planned for 11 October 2026. Verisign and ICANN have spent the past two years rolling out KSK-2024, the successor to the 2017 key that currently anchors DNSSEC validation worldwide. The transition has proceeded smoothly, but any resolver that has not added the new key by the October deadline will fail to validate signed responses, breaking DNS resolution for end users behind it.

How the rollover works

The root zone Key Signing Key (KSK) is the top-level cryptographic anchor for DNSSEC. When a resolver validates a signed response, it traces the chain of trust back to the KSK. To replace the key, ICANN and Verisign follow a multi-year process governed by RFC 5011. The new key is first published in the root zone, and resolvers that support RFC 5011 automatically add it to their trust store after observing it for 30 consecutive days. Operators who manage their own trust anchors must update them manually.

KSK-2024 was generated in 2023 after a hardware refresh. The original HSMs used to protect the key material had reached end-of-support, so the operation migrated to new hardware from a different vendor before generating the key. The public component of KSK-2024 was first published in the root zone in January 2025. Since then, Verisign and ICANN have monitored adoption via RFC 8145 trust-anchor signals sent by resolvers to the root name servers.

Adoption trends and lessons from 2018

The data show that adoption of KSK-2024 has followed a nearly identical curve to the 2018 rollover. By July 2026, over 95 % of resolvers that send trust-anchor signals were using the new key. The sharp increase in February 2025 corresponds to the 30-day RFC 5011 hold-down period: once resolvers had observed the key for 30 days, they added it to their trust store. A small fraction—about 3.5 %—still retain the 2010 key, which was revoked in 2019, while essentially 100 % continue to use the 2017 key until the cutover.

The 2018 rollover offered a cautionary tale. That rollover was originally scheduled for October 2017 but was postponed for a year after operators discovered that some resolvers were sending noisy or contradictory trust-anchor signals. The delay gave software vendors and resolver operators time to update their configurations. The final rollover in October 2018 went smoothly, but the experience underscored the importance of early monitoring and outreach.

What operators need to do

Most resolvers running current software have already added KSK-2024 automatically. However, operators should verify their configurations now. The correct key has a keytag of 38696. Common resolver software stores the trust anchor in these files:

• ISC BIND: bind.keys
• Unbound: root.key
• PowerDNS Recursor: root.key
• Knot Resolver: root.keys

If KSK-2024 is missing, operators should check whether automatic updates are enabled and whether the resolver process has write access to the key storage directory. Manual intervention may be required for resolvers that do not support RFC 5011 or that have disabled automatic updates.