Rolling Root KSK Case Study of 2018 and Beyond

The security of the global Domain Name System (DNS) relies fundamentally on a chain of trust anchored at the DNS root. This chain begins with a cryptographic key known as the Key Signing Key (KSK), specifically the root KSK, which sits at the apex of DNSSEC—the suite of extensions that enable DNS data to be cryptographically verified for authenticity and integrity. Since the signing of the root zone was introduced in 2010, the root KSK has been central to enabling DNSSEC validation worldwide. Yet, like any cryptographic key, the root KSK must be periodically rolled over to maintain operational hygiene and long-term security. The first such rollover, which culminated in October 2018, was a milestone in the evolution of DNS security and an instructive case study in the complexities of managing global cryptographic infrastructure.

The decision to perform the first root KSK rollover was initiated by the Internet Assigned Numbers Authority (IANA) and its operator, Public Technical Identifiers (PTI), under the stewardship of ICANN. The original root KSK, known as KSK-2010, had been in use since the inception of root DNSSEC signing. The rollover plan aimed to replace KSK-2010 with a new key, KSK-2017, a 2048-bit RSA key designed to maintain cryptographic strength well into the future. While the theoretical process of a KSK rollover is straightforward—publish the new key, sign the zone with both keys, transition trust anchors, then retire the old key—the scale and interconnectedness of the global DNS presented unprecedented coordination and risk management challenges.

The root KSK is embedded in millions of validating resolvers and devices, either manually configured or distributed via software updates and vendor defaults. A key concern during the 2018 rollover was ensuring that all DNSSEC-validating resolvers had been updated to trust the new KSK before the old one was retired. Failure to do so would result in resolution failures for all DNSSEC-signed zones, essentially cutting affected resolvers off from verifying the global DNS tree. To assess readiness, ICANN implemented a telemetry collection initiative using RFC 8145, which allowed resolvers to report which trust anchors they were using. This data was instrumental in identifying whether the global infrastructure was prepared to accept the new key.

Initially, the rollover was scheduled for October 2017, but analysis of RFC 8145 data indicated that a non-trivial number of resolvers were still reporting only KSK-2010. Concerned that this subset of systems could face widespread resolution failures, ICANN decided to postpone the rollover to give operators more time to upgrade their configurations. This decision underscored the delicate balance between operational prudence and the necessity of executing key management policies in a timely manner.

After further monitoring and outreach—including technical briefings, public webinars, and coordination with vendors—ICANN rescheduled the rollover for October 11, 2018. On that date, the root zone’s DNSKEY record set was updated to remove the signature generated by KSK-2010, leaving only signatures from KSK-2017. This marked the formal transition of cryptographic trust to the new key. Contrary to earlier fears, the transition was remarkably smooth. A small number of validation failures were observed, largely attributable to misconfigured or outdated resolvers, but no systemic outages occurred. These issues were mitigated by resolvers falling back to non-validating behavior, or by administrators updating trust anchors manually once failures became apparent.

The success of the 2018 root KSK rollover demonstrated that, with sufficient telemetry, communication, and implementation support, even the most sensitive cryptographic infrastructure can be updated in the wild. It also revealed several areas for improvement. For example, the community identified a need for better automation of trust anchor updates. While some resolver software, such as BIND and Unbound, already supported RFC 5011—an automated mechanism for trust anchor rollover—others lacked full compliance or required explicit administrator intervention. As a result, software maintainers and operators were encouraged to adopt RFC 5011 more uniformly to ensure smoother future rollovers.

In the years following the 2018 event, discussions began about when and how to conduct the next rollover. Given the original key was used for eight years, a similar timeline was initially considered. However, the DNS community also explored more frequent rollovers as a way to normalize the process and reduce reliance on exceptional coordination efforts. To that end, the Root KSK Rollover Design Team, composed of DNS experts and community stakeholders, was convened to produce updated recommendations. Their work examined scenarios including regular key changes every five years, approaches to key retirement, and strategies for making rollover events less disruptive and more routine.

Beyond the procedural mechanics, the 2018 KSK rollover had broader implications for DNSSEC trust models and the role of the root zone. It demonstrated the necessity of operational transparency and the importance of global coordination in managing shared internet infrastructure. The telemetry initiative provided a template for future visibility into resolver behavior, while the incident itself underscored that proactive communication with vendors, ISPs, and network administrators is essential for ecosystem health.

The rollover also reinforced the value of resilience in DNSSEC deployments. Many resolvers that experienced validation issues failed gracefully, either by falling back to non-validating resolution or by prompting administrators to intervene. This resilience was a byproduct of good software design and careful planning, which mitigated what could have been catastrophic connectivity issues. It validated the conservative approach taken by ICANN and its technical partners, confirming that DNSSEC could evolve without destabilizing the global DNS.

In conclusion, the 2018 root KSK rollover was not only a landmark in DNSSEC operations but also a proof-of-concept for how the internet’s foundational trust anchors can be securely and reliably updated. The lessons learned from this event continue to shape discussions about cryptographic agility, operational maturity, and the long-term sustainability of DNSSEC. As the internet grows more complex and security-conscious, periodic KSK rollovers will remain an essential practice, reinforcing the resilience of the DNS and maintaining trust in one of the most critical components of the internet’s architecture.

The security of the global Domain Name System (DNS) relies fundamentally on a chain of trust anchored at the DNS root. This chain begins with a cryptographic key known as the Key Signing Key (KSK), specifically the root KSK, which sits at the apex of DNSSEC—the suite of extensions that enable DNS data to be…