The DNS root gets a new signing key on 11 October
The internet's DNS root swaps to a new key-signing key for only the second time ever — and most of the web will never notice, unless a resolver never learned it.
The DNS root is scheduled to switch to a new key-signing key on 11 October 2026 — only the second time the root has changed its key. That key anchors DNSSEC's chain of trust, the mechanism that lets DNS resolvers prove an answer really came from the domain it claims to represent. Change it badly and healthy websites become unreachable while their servers are running perfectly.
What actually changes
The root's signing keys do two different jobs. The zone-signing key signs the root's own DNS records, including the Delegation Signer records that vouch for top-level domains such as .com. The key-signing key signs the DNSKEY set — the published list of the root's public keys. A validating resolver checks that list with the key-signing key it already trusts, then uses the zone-signing key from the list to verify everything else.
The replacement is KSK-2024, identified by key tag 38696. It takes over from KSK-2017, key tag 20326, as the signer of the root's DNSKEY set. The switch happens on 11 October, and ICANN plans to revoke KSK-2017 during 2027, removing it from the root zone and deleting its private key — a separate step from simply retiring it as a signer.
Why a resolver might not know the new key
Resolvers that implement RFC 5011 learn new root trust anchors on their own. The root publishes the replacement alongside the existing key, the key the resolver already trusts signs the set that contains it, and the resolver then waits at least 30 days, rechecking the signed records, before accepting the newcomer. KSK-2024 has been in the root's DNSKEY set since 11 January 2025, which gave that process room to run.
Cloudflare took a more direct route, adding KSK-2024 to its resolver's built-in trust anchors in July 2024 beside KSK-2017. The company says the first rollover in 2018 showed that software upgrades and moves between machines can wipe a resolver's learned trust-anchor state, so baking the key in removes the dependency on state surviving. Its 1.1.1.1 and Gateway DNS services already trust the new key, so customers have nothing to do.
How to check your own resolver
Cloudflare's readiness test asks the resolver your browser uses two opposite questions using the RFC 8509 root key trust anchor sentinel. The names is-ta-38696 and not-ta-38696 are DNSSEC-signed, and a resolver with sentinel support either returns the answer or replaces it with SERVFAIL depending on whether it trusts KSK-2024. The same two queries can be run directly against 1.1.1.1. The page also checks that an ordinary signed name resolves and that a deliberately broken DNSSEC name is rejected, so a blank result reads as an unsupported protocol rather than a missing key.
Most site operators need to do nothing at all. Anyone running a DNSSEC-validating resolver should confirm it trusts KSK-2024 and follow their vendor's instructions to add the trust anchor if it is absent, well before the switch rather than after it.
The rollover keeps RSA/SHA-256, so it replaces a key pair rather than the signature algorithm. ICANN has proposed a later move to ECDSA P-256, and 1.1.1.1 already validates ML-DSA-44 signatures, but a post-quantum root would need a post-quantum key-signing key, and therefore another rollover. Cloudflare's argument is that exercising trust-anchor distribution now is what makes that one survivable.
Our opinion
A key that anchors the entire chain of trust for the web, rotated twice in eight years, is a strange kind of engineering discipline. IANA's own idealises a three-year interval, and ICANN has attributed the gap since 2018 to pandemic disruption and hardware upgrades around the private signing key. Neither explanation is unreasonable; both are also the reason this weekend matters more than it should. The less often you practise a procedure as unforgiving as this, the more of it you are doing for the first time.
The genuinely new part of KSK-2024 is not the key, it is the sentinel. In 2018 operators could publish a new trust anchor and then had almost no way to ask resolvers whether they had kept it — you found out when traffic broke. RFC 8509 turns 'is this key trusted' into a query any DNSSEC-signed domain can answer, and Cloudflare has implemented it in 1.1.1.1 ahead of the switch. That is the sort of unglamorous operator tooling that quietly removes an entire class of outage, and it deserves to be copied by every resolver worth using.
The algorithm question is where I part company with the patience on display. The 2018 post said a successful rollover would open the door to discussing an algorithm change, and eight years on the root still signs with RSA. Post-quantum DNSSEC needs a new key-signing key at the root, a way to get resolvers to trust it, and software that verifies the new signatures — which means the industry will be doing this exercise again under more pressure than today. Rotating the key while the algorithm stays the same is the cheap rehearsal. Fine. But rehearsing for eight years is not practice, it is avoidance.