Tomorrow, something very small will change at the top of the DNS. One key will start signing. Another will stop. For almost everyone on the internet, absolutely nothing will happen. That uneventful outcome is the product of years of planning, because the thing being changed is one of the most consequential pieces of shared infrastructure on the planet: the root key-signing key, the cryptographic trust anchor for DNSSEC, the system that lets a DNS resolver prove an answer is authentic and unmodified.

On October 11, 2026, the root zone changes its key-signing key for only the second time ever. The first time was in 2018. This is one of the largest coordinated security operations the internet performs, and the explicit goal is that you never hear about it.

The key that holds up everything

Nearly every website visit begins the same way. Your device asks a recursive resolver, a DNS lookup service run by your ISP, your employer, or a public provider, to translate a domain name into an IP address. DNSSEC adds a layer of cryptographic proof on top of that lookup, so the resolver can confirm the answer was not forged or tampered with in transit.

That proof is a chain of signatures, and every link in the chain traces back to a single starting point. At the top sits the root key-signing key. The root KSK signs the root zone's DNSKEY record set, which authenticates the root zone-signing key, which authenticates the records below, with Delegation Signer records linking each level down to your domain. Validating resolvers hold the root KSK's public half as a hardcoded trust anchor. There is exactly one of it, and the entire chain is only as trustworthy as that key.

The outgoing key, KSK-2017 (key tag 20326), has been that anchor for eight years, taking over on October 11, 2018. Tomorrow, exactly eight years later, KSK-2024 (key tag 38696) becomes the signer of record.

You cannot reboot the internet's trust. Changing the master key takes 21 months, two keys, and one very long hold-down.

Why changing it is so hard

Enjoying this story?

Get the five most important stories in tech, every morning. Free.

The difficulty is not cryptographic. It is logistical. You cannot push an update to every validating resolver on the planet, many of which sit in places nobody has inventoried for years: appliances in closets, golden images, long-running virtual machines. So the rollover is deliberately slow.

The successor key was generated by ICANN back in April 2024. It was published in the root zone alongside the old key on January 11, 2025. Nothing changed that day. Both keys simply appeared side by side in the root's DNSKEY set, giving the world's resolvers nearly two years to learn the new key before it ever signed anything.

Learning happens automatically for most resolvers, through a mechanism called RFC 5011. It lets a resolver adopt a new trust anchor on its own, but only after a hold-down of roughly 30 days of regular querying, a safety window designed so that an attacker cannot slip in a bogus key. The mechanism works well, with one big assumption: the resolver has to have been up, running, and querying through the transition. A validator powered off for a month, a virtual machine snapshot resumed after the hold-down window, a read-only key store, an outdated golden image, any of these can wake up on October 11 trusting only the old key.

The 2018 rollover taught the industry what the edge cases look like. Back then, some resolvers lost their learned trust in the new key during software upgrades or machine migrations. Publishing the key well in advance, Cloudflare noted afterward, was only part of the job. Knowing whether resolvers had actually retained it was the harder half.

What breaks, and how it looks

Root KSK Rollover: The Timetable

Changing the internet's master key takes 21 months of staged transitions.

Apr 2024Key generated
ICANN generates the successor key, KSK-2024, key tag 38696.
Jan 11, 2025Published
The new key appears in the root zone alongside KSK-2017. Nothing changes yet.
Feb 2025Auto-trust
Resolvers using RFC 5011 begin a hold-down period before adopting the new key as a trust anchor.
Oct 11, 2026Rollover
KSK-2024 starts signing the root zone. KSK-2017 stops, exactly eight years after it took over.
Jan 2027Retirement
The old key leaves the active set, is revoked, and its private half is deleted.

KSK-2017: key tag 20326. KSK-2024: key tag 38696. Algorithm unchanged: RSA with SHA-256.

The failure mode when a resolver misses the window is, as one engineer put it, beautifully silent. A validating resolver that does not trust KSK-2024 will reject the root zone's signatures and return SERVFAIL, not just for signed domains but for everything it serves. Websites will not load. Applications cannot connect. Nothing in the error will say "trust anchor."

The telltale pattern for anyone troubleshooting: many unrelated sites fail at once while direct IP connectivity still works. That is what makes this operation a diagnostic story as much as a security story. On October 11, a sudden wave of "the internet is down" reports will, for some unlucky operators, actually mean "our resolver missed a key rotation that was announced in 2024."

For the record: the cryptography itself is not changing. This rollover keeps the same algorithm, RSA with SHA-256. The event replaces the key pair, not the math. A separate, future project will move the root to a different signing algorithm, and a post-quantum key is on the longer horizon.

The timetable

Server racks in a data center
The root servers underpin every name lookup on the internet. On October 11, they start signing responses with a new key. (Photo: Infrastructure Journal)

The full schedule reads like a slow-motion relay. April 2024: ICANN generates KSK-2024. January 11, 2025: the key is published in the root zone. February 2025 onward: RFC 5011 resolvers begin the hold-down and adopt the new trust anchor automatically. October 11, 2026: KSK-2024 starts signing the root zone and KSK-2017 stops. January 2027: the old key leaves the active set, gets revoked, and its private half is deleted, closing the rollover.

Home users do not need to do anything. If your router takes DNS from your ISP automatically, or you use a maintained public resolver, the operator owns this transition, and the major ones already trust the new key. Cloudflare, which published detailed readiness guidance this week, says its 1.1.1.1 and Gateway DNS services have trusted KSK-2024 all along.

Resolver operators are the ones with homework. The checklist: confirm key tag 38696 is present in your trust-anchor configuration files, confirm the running daemon has actually loaded it into memory (config and memory are not the same thing), and run RFC 8509 trust-anchor sentinel tests from the networks relying on those resolvers. Cloudflare has implemented the sentinel protocol in 1.1.1.1 and operates a readiness test that asks the resolver your browser uses whether it trusts the new key.

What comes after October

The old key's retirement in January 2027 will officially end this rollover. The longer roadmap is already forming. A planned algorithm rollover will move the root signing key to ECDSA, and work is underway toward an eventual post-quantum KSK, as the industry prepares the DNS for a world where quantum computers exist. Each of those will be its own multi-year, carefully staged operation, because there is no shortcut for changing the internet's trust.

That is the real story here. The internet runs on quiet maintenance like this: no product launch, no keynote, just a key swap performed in slow motion over 21 months so that one Sunday, everything keeps working. If the operation goes as planned, tomorrow's biggest infrastructure event will be the one you never heard about. And if your sites all load fine on Sunday morning, that silence is the sound of it working.