DNS root switches to KSK-2024 on October 11, 2026 in only its second rollover

On October 11, 2026, the DNS root zone is scheduled to begin signing with a new key-signing key, something that has happened only once before in the history of the DNS. According to a Cloudflare blog post, validating resolvers must already trust the replacement key, KSK-2024, when the switch takes effect. Those that do not may fail DNSSEC validation and leave their users unable to reach websites that are otherwise perfectly healthy.

How the root key anchors DNSSEC

DNSSEC lets resolvers verify that DNS answers are authentic by checking digital signatures. Verification follows a chain of trust: the root vouches for top-level domains such as .com through DS records, and each parent zone similarly vouches for its children. The root has no parent, so a validating resolver instead starts from a trust anchor, a root public key or its fingerprint that the resolver already trusts.

The root uses two kinds of signing keys. A zone-signing key signs ordinary root records, including the DS records for top-level domains, while the key-signing key signs the root's DNSKEY set, the list of keys the root publishes. A resolver uses its trusted KSK to validate that list, then takes the ZSK from it to check the root's remaining records. The rollover replaces the key at the very top of this chain: KSK-2024, identified by key tag 38696, takes over from KSK-2017, key tag 20326, as the signer of the DNSKEY set.

How resolvers learn the new key

RFC 5011 automates the process. The root publishes the new KSK alongside the existing one, and the old key keeps signing the set, so a resolver can verify the newcomer with the key it already trusts. It must then see the new key in validated DNSKEY records for at least 30 days, and verify those records again, before accepting it as a trust anchor. Cloudflare notes that KSK-2024 has been part of the root's DNSKEY set since January 11, 2025, giving resolvers with automatic updates a long runway before the October 2026 signing change.

Automation has a known weakness. During preparations for the first rollover in 2018, Cloudflare observed that some resolvers lost their learned trust-anchor state when software was upgraded or instances moved between machines. To avoid relying on learned state, Cloudflare added KSK-2024 directly to the built-in trust anchors of its resolver software in July 2024, so a fresh instance trusts the new key from startup. Users of 1.1.1.1 and Gateway DNS need to take no action.

Checking a resolver with the sentinel test

In 2018 there was no practical way for users to confirm whether the resolver answering their queries had retained the new key. RFC 8509 fills that gap with the root key trust anchor sentinel, specially named domains that a supporting resolver answers differently depending on which keys it trusts. A query for a name containing is-ta-38696 returns a valid signed answer only if the resolver trusts KSK-2024, while the matching not-ta-38696 name returns SERVFAIL in that case; the two outcomes reverse when the key is missing.

Cloudflare has implemented the sentinel in 1.1.1.1 and built a readiness test on it. The test includes control checks, confirming that an ordinary signed name resolves, that a deliberately invalid DNSSEC response is rejected, and that the resolver responds to a sentinel query for the current root key. This separates an inconclusive result, such as a resolver without sentinel support, from evidence that the new key is actually missing. Cloudflare also cautions that the browser-based test probes whichever resolver the browser uses, which Secure DNS settings or a VPN may change.

What operators should do

Most website operators need to change nothing, Cloudflare says. Operators of DNSSEC-validating resolvers should verify that their systems trust KSK-2024 and follow their software vendor's instructions for updating trust anchors if they do not. The stakes are illustrated by earlier rollover failures Cloudflare documented for the .de and .al top-level domains, where sites kept working but became unreachable for users whose validation failed. A root-level failure would reach further still: a resolver that rejects the new root key may be unable to resolve names under any top-level domain.

Why it matters

The root KSK sits at the base of DNSSEC's entire chain of trust, so this change touches every signed domain at once. The failure mode is unusually broad: a resolver without trust in KSK-2024 can treat valid answers as bogus, which looks to its users like the whole Internet being down. The 2018 experience showed that automated key learning can silently break during upgrades or migrations, which is why shipped trust anchors and an external verification method such as the RFC 8509 sentinel both matter. For anyone running a validating resolver, a short readiness check before October 11, 2026 is cheap insurance against an outage that would be very hard to diagnose from the outside.