Co-authored by Duane Wessels (Verisign) and Roy Arends (ICANN).

Roughly a year and a half ago, Verisign and the Internet Corporation for Assigned Names and Numbers (ICANN) began the important, multi-year process of updating the cryptographic key that secures the authoritative Domain Name System (DNS) root zone. This work has been largely invisible to the public, but vital to the security of many everyday online activities.

As we near the end of the deployment of this new key—called KSK-2024, scheduled for completion in October 2026—we’d like to review what we’ve learned and share our observations. This blog post, paired with our first blog post on the topic from March 2025, paints a complete picture of a process that has gone smoothly and predictably.

DNSSEC and the Root Zone

The Domain Name System Security Extensions (DNSSEC) are an increasingly important component of internet security. DNSSEC forms the secure basis for several aspects of online interactions, including authenticating destination addresses, securing email transactions, validating domain name relationships, and more.

The DNS root zone was originally signed with DNSSEC in 2010, and the root zone Key Signing Key (KSK) was first updated (or “rolled over”) in 2018. Now, in 2026, we’re about to update the root zone KSK again.

The 2017-2018 KSK Rollover

The first root zone KSK rollover was originally scheduled to take place in October 2017. In the months leading up to the rollover, we began to collect and observe data from a recently developed feature known as trust anchor signals, described in RFC 8145. These signals, from a relatively small population of DNS clients, were “noisy”: they frequently contained what seemed to be false negatives, in that some resolvers signaled use of trust anchor keys that were never deployed for the root zone, and others were contradictory, sometimes indicating possession of the new KSK and at other times only the old KSK, which might happen if multiple DNS resolver clients share a single IP address.

Out of an abundance of caution, the KSK rollover was postponed for one year in order to analyze our findings and determine how to resolve the issues we were seeing. While this gave operators time to re-examine their configurations, it also gave us time to reach out to software developers who neglected to update the KSK in their software codebase, and to resolver operators who also apparently were not yet using the new KSK.

The rollover successfully took place one year later, in October 2018.

Lessons Learned

The outcomes of the 2018 KSK rollover are described and discussed in ICANN’s “Review of the 2018 DNSSEC KSK Rollover” report and the peer-reviewed paper “Roll, Roll, Roll your Root,” both published in 2019.

While there were a few disruptions that could have been prevented had organizations been better prepared and their systems properly configured, there was nothing to indicate that the proper mechanisms malfunctioned. With this in mind, we’re looking towards execution of the current KSK rollover in 2026.

The original plan was to roll the KSK on a three-year cycle. However, the COVID-19 pandemic disrupted operations in 2021, when in-person key signing ceremonies had to be replaced with remote attendance. It wasn’t until 2022 that we could resume normal, in-person ceremonies.

In 2023, a new KSK was generated but had to be retired when the Hardware Security Modules (HSMs), used to protect the key material, had reached end-of-support. That meant a key generated at that point would outlive the supported lifetime of the hardware. To address this, the operation transitioned to new HSMs from a different vendor, after which the current KSK, KSK-2024, was generated.

The Current KSK Rollover

The KSK rollover currently underway began back in 2024. The new KSK was generated and then replicated at key signing ceremonies mid-year. In January 2025, the new KSK’s public component was first published in the root zone.

Through the process documented in RFC 5011, most internet resolvers will notice the new KSK and start a “virtual timer” of sorts. If the resolver observes—and can validate—the new KSK for a period of 30 days, it can be added to the local set of trusted keys. This behavior is something we can track via the RFC 8145 trust anchor signals, which are transmitted to the root name servers. The graph below indicates the percentage of signal-sending resolvers that are using the current key (KSK-2017) and the new key (KSK-2024), as well as the old key (KSK-2010).

The sharp increase in KSK-2024 signals in February 2025 reflects the RFC 5011 process: 30 days after publication, the majority of resolvers had added the new key to their trust store.

Essentially 100% of sources indicate they’re using KSK-2017. Without it, DNSSEC validation on the internet would fail today. About 3.5% still retain KSK-2010, created in 2010 and revoked in 2019.

Comparing the two rollovers reveals a striking consistency. Aligning the datasets to a common starting point, when each KSK was first published in the root zone, shows nearly identical adoption curves.

The similarities are notable, except for the anomalous dip in KSK-2017 signals, which eventually recovered to previous levels (remember that the population of signaling resolvers was much smaller in 2018 than it is today). Both rollovers show very similar trends leading up to and immediately following KSK pre-publication. After some 500 days, both rollovers show adoption of the incoming key above 95%.

Next Steps: Ensure You’re Prepared

On Oct. 11, 2026, the root zone will begin publishing DNSKEY RRsets signed exclusively by KSK-2024. Any DNSSEC-validating resolver that has not yet added KSK-2024 to its trust anchor set will experience DNS resolution failures from that date.

Most resolvers running current software have been shipped with KSK-2024 or will have picked up KSK-2024 automatically via RFC 5011. However, system administrators should verify this now: the correct key has a keytag of 38696. The table below shows where to find trust anchor configuration files for common resolver software.

If KSK-2024 is not present, administrators will want to check whether automatic trust anchor updates are enabled and whether the resolver process has “write” access to the key storage directory.

Wrapping Up

As we near the end of the current rollover process, we take stock of the lessons we’ve learned—during this rollover and the previous one—and consider them invaluable guidance as we move forward. Verisign and ICANN will continue to work together to maintain the security, stability, and resiliency of the DNS, with an eye toward upholding operational excellence and high-assurance services and infrastructure.