DNS Root Key Rollover: New Signing Key Deploys 11 October 2026
On 11 October 2026, the internet's root DNS zone will begin using a fresh cryptographic key, completing a multi-year DNSSEC rollover designed to keep global dom…
The internet's core directory service will take one of its rarest and most critical security steps on 11 October 2026, when the Domain Name System root zone switches to a brand-new Key Signing Key (KSK). This key is the ultimate digital trust anchor for DNSSEC, the system that cryptographically proves DNS answers are authentic and haven’t been tampered with. The replacement is the culmination of a carefully choreographed, years-long process known as a root KSK rollover, and it marks only the second time in internet history that the top-level signing key has been rotated.
The original root KSK was first deployed in 2011. The first rollover took place in 2017, but plans for the current rollover were delayed twice, once in 2020 and again in 2023, due to unforeseen operational circumstances. Now, the third KSK in the internet’s history is about to enter active service. On 11 October, the new key pair will begin signing the root zone, and the previous key will immediately stop being used for signing. However, the old key will remain visible in the root zone until early 2027 to allow resolvers time to complete the transition.
Duane Wessels, a Fellow at Verisign who researches DNS and participates in the ICANN/IANA key ceremonies, joined the PING podcast to explain the rollover and share recent measurement work. Together with Roy Arends from ICANN, Wessels published two detailed blog posts tracking resolver behaviour during the rollover: “The 2024-2026 Root Zone KSK Rollover: Initial Observations and Early Trends” in March 2025, and “The 2024-2026 Root Zone KSK Rollover: Updates and Observations” in July 2026. Their analysis shows how understanding evolved as the rollover progressed, and it benefits from a signalling mechanism that simply wasn’t available during the 2017 rollover.
That signalling mechanism is defined in RFC 8145, which lets DNSSEC validators report which Trust Anchors (TAs) they have installed and are actively using. A Trust Anchor is a known good copy of a public key that a resolver uses to start the chain of trust for DNSSEC. By watching RFC 8145 signals, the researchers could build time-series data showing exactly when and how quickly resolvers around the world adopted the new root KSK. This is a far clearer picture than the indirect measurements that were possible last time. The new KSK was first published in the root zone in January 2025 and became eligible for automatic installation by validating resolvers through the RFC 5011 automated trust anchor update process in February 2025. Since then, network operators have had many months to ensure their systems adopt the new key before the signing transition.
Verisign contributes to the rollover in several critical ways. It is involved in generating the cryptographic key material itself, participates in the tightly controlled ICANN/IANA key ceremonies where private keys are managed inside a secure facility in Culpeper, Virginia, and operates the J root server, one of the strategic anycast DNS root servers, giving it unique large-scale operational visibility into global DNS traffic. This combination of hands-on ceremony participation and real-world resolver data makes the research especially valuable.
The root KSK is the single foundation of all DNSSEC-protected data worldwide. When a resolver validates a domain’s DNS records, it follows a chain of digital signatures that ultimately ends at this root key. If a resolver cannot reach that trust anchor or has the wrong one, every DNSSEC-signed lookup it performs can fail: websites become unreachable, email delivery can break, and any service that relies on authentic DNS answers can stop working. That is why root KSK rollovers are never done quickly, they are multi-year events with extensive monitoring, pre-publication of the new key, and a long overlap period.
For everyday internet users and website owners, the rollover should be completely invisible, provided their DNS resolver is properly maintained. Most modern encrypted DNS services, including privacy-first resolvers like AEU DNS, already validate DNSSEC by default and handle trust anchor updates automatically using RFC 5011, so no manual intervention is needed at the user level. Network operators who run their own validating resolvers, however, should confirm that their software has accepted the new root KSK and is ready to use it on 11 October 2026. Checking the trust anchor configuration now, before the signing key actually switches, avoids any risk of DNSSEC validation failures when the old key stops signing the root zone.
Termini spiegati
- DNSSEC
- A set of security extensions to the DNS that uses digital signatures to prove that DNS answers have not been forged or altered.
- Key Signing Key (KSK)
- A long-term cryptographic key used to sign other DNS security keys; the root KSK is the single most important key in the global DNSSEC chain of trust.
- Trust Anchor (TA)
- A pre-installed public key that a DNS resolver trusts completely and uses as the starting point to verify all other DNSSEC signatures.
- RFC 5011
- A standard that lets DNS resolvers automatically update their trust anchors when a new signing key appears, as long as it is correctly signed by the old key.
- RFC 8145
- A signalling protocol that allows DNS resolvers to report which trust anchors they have installed, giving researchers and operators real-time visibility into key adoption.
Come proteggerti
- If you run a validating DNS resolver, confirm that it has auto-installed the new root Key Signing Key (KSK) via the RFC 5011 mechanism, or manually update your trust anchor file using the key material published by IANA.
- Regularly check the IANA DNSSEC status page, which posts the official schedule and any operational updates about the root KSK rollover.
- Choose a DNS resolver that supports DNSSEC validation and automatic trust anchor updates; modern encrypted DNS services handle this behind the scenes without user action.
- If you are responsible for a corporate or home network, test DNS resolution for DNSSEC-signed domains like `sigfail.verteiltesysteme.net` (which should fail) and `sigok.verteiltesysteme.net` (which should succeed) to verify validation is wo
