The keys to the Internet change on October 11. Are you ready?

What changes on October 11, 2026

The DNS root is scheduled to replace its key-signing key (KSK) for only the second time in its history. This key is the starting point of DNSSEC's chain of trust, which allows resolvers to authenticate DNS answers cryptographically. The event is called a KSK rollover: the new key, KSK-2024, takes over signing the root's DNSKEY record set from KSK-2017.

KSK-2024 carries key tag 38696; KSK-2017 carries key tag 20326. Every validating resolver must trust KSK-2024 before the switch, or sites may stop resolving even while the servers behind them are healthy.

Trust anchors and the chain that depends on them

A DNSSEC-validating resolver checks signatures on DNS records and confirms that the keys behind those signatures belong to the right domains. For cloudflare.com, that runs from the root to .com and then to the domain itself: each parent publishes a Delegation Signer (DS) record holding a fingerprint of its child's public key, and .com publishes the DS record that lets a resolver check cloudflare.com's key.

The root has no parent, so the chain needs a different starting point. A resolver begins with a root public key — or its fingerprint — that it already trusts: a trust anchor. The root splits its signing work between two roles. The zone-signing key (ZSK) signs the root's records, including the DS records for top-level domains. The KSK signs the DNSKEY record set, the list of the root's own published keys. A resolver verifies that list with the trusted KSK, then uses the ZSK named in the list to verify everything else. For the root, trust comes from the resolver's configured anchor rather than a DS record in a parent.

Automatic key learning and why we don't rely on it

RFC 5011 allows a resolver to pick up a new trust anchor on its own. The root publishes the replacement KSK next to the current one, with the existing key still signing the set, so a resolver can verify the records that contain the new key using the key it already believes. It then holds off: at least 30 days of repeated signed DNSKEY checks during which the new key must keep appearing, followed by another successful verification of the records containing it.

KSK-2024 has been in the root's DNSKEY set since January 11, 2025 under this arrangement. Because KSK-2024 refers to the root zone for the third rollover, if the resolver retains its learned state through software upgrades and machine changes, it should have completed the 30-day acceptance period long before October 11, 2026. That state is not always retained — during the first rollover in 2018, software upgrades and moves between machines caused resolvers to lose learned anchors — so our resolver does not depend on RFC 5011 alone.

Built-in anchors, and a way to ask the resolver

We added KSK-2024 directly to our resolver software's built-in trust anchors in July 2024, alongside KSK-2017, so a resolver running the updated software starts up trusting the new key. Users of 1.1.1.1 and Gateway DNS need take no action.

RFC 8509 defines the root key trust anchor sentinel, which uses ordinary DNS queries for specially named domains to ask a supporting resolver whether it trusts a particular root key. Our readiness test applies this to KSK-2024 and has been implemented in 1.1.1.1 ahead of the rollover. Two names ask opposite questions: is-ta-38696 asks whether the key is trusted, and not-ta-38696 asks whether it is not trusted.

Both have valid DNSSEC-signed address records. A resolver with sentinel support validates those records first, then either returns the response or replaces it with SERVFAIL depending on its answer to the question.

A SERVFAIL for not-ta-38696 is the expected result when KSK-2024 is trusted, because the resolver deliberately rejects the "not trusted" query.

Sentinel labels like root-key-sentinel-is-ta-38696 work under any DNSSEC-signed domain; we use dnstest.dev. The two queries can be run directly against 1.1.1.1:

$ dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer

; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44476
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; ANSWER SECTION:
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.6.197
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.7.197

$ dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer

; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3285
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

Reading the result correctly

The test site also checks that an ordinary signed name resolves, that a deliberately invalid DNSSEC answer is rejected, and that the resolver speaks the sentinel for the current root key. Those controls separate a real result from a failed lookup or an unsupported protocol: if sentinel support cannot be established, the result is inconclusive rather than evidence that the key is missing.

Know which resolver you are testing. The browser test checks the resolver your browser uses, which Secure DNS or a VPN can alter. The dig commands point explicitly at 1.1.1.1 — and note that those go to a Cloudflare resolver, so they are not an external check on whether our resolvers trust the key. Both are snapshots of the resolver path answering those particular requests.

Same algorithm, new key material

KSK-2017 and KSK-2024 both use RSA/SHA-256, so the rollover swaps key pairs without changing how signatures are produced or verified. In our 2018 write-up we said a successful rollover would open the door to discussing an algorithm change. Eight years on, the root still uses RSA. Replacing the key is still worthwhile: it limits how long one private key stays in service and rehearses distributing new trust anchors, updating resolvers, and retiring old keys. The first rollover showed those steps can fail even when the cryptography is sound, which is why checking resolver state matters as much as publishing the key.

The schedule, then quantum

The Internet Assigned Numbers Authority (IANA) targets an idealized three-year rollover interval, balancing regular practice against the cost and risk of changing the root key too often. The actual gap since 2018 has been longer; The Internet Corporation for Assigned Names and Numbers (ICANN) attributes the delay to pandemic disruption and upgrades to the hardware protecting the private signing keys.

October 11 changes which KSK signs the DNSKEY set. The work continues into 2027, when ICANN : ICANN says it will revoke KSK-2017, remove it from the root zone, and delete its private key in 2027. Those are separate actions: stopping a key from signing is not the same as removing trust in it.

Longer term, ICANN has raised the possibility of moving the root to ECDSA P-256, which yields smaller keys and signatures than RSA. That is not a post-quantum algorithm, and no algorithm change is part of this October's work. For DNSSEC to be post-quantum end to end, signed domains, their parent zones, and the root would all have to adopt post-quantum cryptography — which is why rollover practice matters now. Two things are worth separating: the signer change on October 11, and revocation of the old key in 2027. It is possible to trust KSK-2024 while still accepting KSK-2017, or the reverse. The test above reports on KSK-2024 only.