Every address on the Internet, every name typed into every browser, ultimately hangs from a single cryptographic key. It is changed almost never — on October 11, 2026, for only the second time in history. As Cloudflare explains on its blog, the DNS root is scheduled to replace its key-signing key, the KSK, which anchors the chain of trust that lets resolvers authenticate answers using cryptographic signatures. The ceremony is called a rollover. Resolvers that validate DNSSEC must trust the new key before the switch, or perfectly healthy websites could become unreachable.
Most website operators need do nothing. The burden falls on those who run DNSSEC-validating resolvers: check that yours trusts the new root key, KSK-2024, and follow your software vendor’s instructions to update its trust anchors if it does not. Anyone whose domains sit on Cloudflare’s DNS, or who relies on 1.1.1.1 and Gateway DNS, can stay in their chair — those systems already trust the new key.
The chain that must begin somewhere
A resolver’s work is a walk down a ladder of signatures. DNSSEC lets it check digital signatures on DNS records to confirm they are authentic and unchanged, and to confirm that the public keys verifying those signatures belong to the right domains. For cloudflare.com, the chain descends from the root to .com, then to the domain itself; each parent publishes a Delegation Signer record, a fingerprint of its child’s public key. But the root has no parent. Nothing vouches for it. So the chain must begin with a key the resolver already trusts — a trust anchor.
The root keeps two keys with two duties. The zone-signing key, the ZSK, signs the root’s DNS records, including the DS records for top-level domains like .com. The key-signing key signs the list of public keys the root publishes, the DNSKEY record set. The resolver uses its trusted KSK to verify that list, then uses the ZSK from within it to verify everything else. Cloudflare’s earlier post-mortems of the failed .de and .al rollovers showed what a broken check means: sites working normally and still unreachable. A failed root rollover is that failure everywhere at once — users cut off from websites under any top-level domain. The incoming key is KSK-2024, key tag 38696; it replaces KSK-2017, key tag 20326, as signer of the root’s DNSKEY set.
A thirty-day novitiate
Trust in a new key is not granted; it is earned on a schedule. Under RFC 5011, the root publishes the new KSK alongside the existing one in its DNSKEY set, still signed by the old key, so a resolver can use the key it already trusts to verify the records carrying the replacement. Before accepting the newcomer as a trust anchor, the resolver waits at least 30 days, keeps checking the signed DNSKEY records, and must verify them successfully again at the end. KSK-2024 has been published there since January 11, 2025 — time enough, ahead of the October 11, 2026 signing change, for resolvers with automatic trust-anchor updates to find it. Each resolver’s waiting period begins when it first sees and verifies the key.
Cloudflare chose not to rely on memory. It added KSK-2024 directly to its resolver software’s built-in trust anchors in July 2024, alongside KSK-2017, so the new anchor is present from startup. The reason is a scar from the first rollover in 2018: software upgrades and moves between machines caused some resolvers to lose the trust-anchor state they had learned automatically. Publishing a key far in advance, the company found, is only part of the job; one must also know the resolvers kept it. And back then, there was no practical way for a user to ask.
This time, ask the resolver
RFC 8509 supplies the question. It defines the root key trust anchor sentinel: ordinary DNS queries, made to specially named domains, that ask a supporting resolver whether it trusts a particular root key. Cloudflare has implemented the protocol in 1.1.1.1 and built a rollover readiness test website on it. Two names pose opposite questions — is-ta-38696 asks whether the key is trusted, not-ta-38696 asks whether it is not. Both names carry valid DNSSEC-signed address records; a supporting resolver validates them, then either returns the answer or replaces it with SERVFAIL depending on what it trusts. For a validating resolver, a SERVFAIL on the “not trusted” query is the good news — the resolver is deliberately rejecting it.
Sentinel labels such as root-key-sentinel-is-ta-38696 work under any DNSSEC-signed domain; Cloudflare uses dnstest.dev, and anyone can put the two queries to 1.1.1.1 directly with dig. The website adds controls — an ordinary signed name must resolve, a deliberately invalid DNSSEC name must be rejected, and the resolver must answer a sentinel query for the current root key — to separate a meaningful result from a failed lookup or an unsupported protocol. If sentinel support cannot be established, the result is inconclusive; it does not mean the key is missing. The browser test checks whichever resolver the browser happens to use, which Secure DNS or a VPN can affect. A snapshot, not a guarantee — but a snapshot is more than 2018 ever offered.
One thing will not change on October 11: the mathematics. KSK-2017 and KSK-2024 both use RSA/SHA-256; the rollover replaces the key pair while keeping the same method for creating and verifying signatures. After the first rollover, Cloudflare wrote that success would open the door to discussions of changing the algorithm. Eight years later, the root still uses RSA. Rotation remains worth the trouble regardless — it bounds how long a single private key stays in service, and it drills the machinery of distributing anchors, updating resolvers and retiring old keys. As 2018 taught everyone watching, those steps can fail even when the cryptography itself works perfectly. The lock is changed this week. Whether every doorkeeper has the new key is the open question — and this time, at least, the question can be asked.