The DNS root changes its key on 11 October and will silence frozen resolvers
On 11 October 2026 the DNS root zone replaces its key-signing key KSK-2017 with KSK-2024, the second rollover since the root was first signed in 2010. Any DNSSEC-validating resolver that does not already trust the new key will stop resolving every name: the job is to find, before Sunday, the resolvers whose trust anchor has been frozen.
Sunday, 11 October 2026. The DNS root zone changes the key that signs its key set: KSK-2024 (key tag 38696) starts signing, KSK-2017 (key tag 20326) stops, after eight years in the job. Only the second time. It is the second rollover of the root key-signing key since the root was signed in 2010. Every name. A DNSSEC-validating resolver that does not already trust the new key stops resolving every name, signed or not. Why it matters: the vast majority of resolvers picked up the new key automatically in February 2025 — but the ones whose trust anchor was frozen into an image, a config file, or an appliance nobody updates will fall into SERVFAIL on Sunday, with no warning.
What changes, and what does not
DNSSEC validation is a chain. Your zone’s keys are vouched for by a DS record at the parent, the parent’s keys by a DS at the root, and the root zone is signed by the ZSK (zone signing key), which Verisign rotates every quarter. The ZSK is itself signed by the KSK (key signing key). Nothing signs the KSK: a resolver trusts it because a copy — the trust anchor — is stored in the resolver’s own configuration.
On 11 October, only that top link changes. Before, the root DNSKEY set is signed by KSK-2017 (key tag 20326); after, it is signed by KSK-2024 (key tag 38696). Both are 2,048-bit RSA/SHA-256 keys (algorithm 8). Everything below the KSK stays put: the ZSK schedule, the TLD DS records, your zone. But a resolver that cannot verify the first link can verify nothing further down, so every lookup fails — including toward unsigned zones.
That local copy is the weak point of the design. Every other DNSSEC key can be replaced by publishing new records. Replacing the root KSK means changing a setting inside every validating resolver on the internet, and nobody holds the list of those resolvers.
Why most resolvers will see nothing
The mechanism that carries resolvers across is RFC 5011. A resolver that sees a new KSK in the root DNSKEY set, signed by a key it already trusts, starts a timer. If the new key is still there after a 30-day hold-down, the resolver adds it to its anchors and writes it to disk. For a resolver running on 11 January 2025 — the day KSK-2024 was published in the root — the timer expired on 10 February 2025. More than 95% of resolvers that announce their anchors to the root servers now list KSK-2024, per Verisign and ICANN.
The write to disk is exactly where the system fails without telling anyone. A resolver in a container with a read-only filesystem, or redeployed weekly from an image, restarts with the anchor baked into the image and begins the 30 days again — never reaching the end. Current releases of Unbound, BIND and Knot Resolver ship both keys, so a fresh image is fine. An image built in 2023 and restarted ever since is not.
Three other setups deserve a look. Configurations that pin the anchor by hand (BIND’s trusted-keys or static-key, Unbound’s trust-anchor instead of auto-trust-anchor-file) never update, by design. PowerDNS Recursor does not implement RFC 5011 at all, so its anchors arrive with the package, and an old package means an old key. Finally, a local forwarder is exposed if it validates itself: dnsmasq with DNSSEC on, or Unbound forwarding to 8.8.8.8, still checks signatures against its own anchor, whatever Google trusts on its side.
What the failure looks like, and how to fix it
The symptom at the application is a blanket SERVFAIL: everything fails, signed or not. In the logs, Unbound reports “failed to prime trust anchor” and BIND reports “no valid signature found” for the root DNSKEY set. The repair is to install the new anchor and restart: upgrade the package, or run unbound-anchor, which fetches the current keys from IANA’s root-anchors.xml. If users are already down and the fix will take a while, switching validation off for an hour is a defensible stopgap — the call Cloudflare made for .de.
Before Sunday, you can test a resolver in a single command. A DNSSEC query to the root should return both keys, and a query for a signed name should resolve without SERVFAIL:
# 1. Does the resolver see BOTH KSKs (20326 and 38696) in the root DNSKEY set?
dig +dnssec DNSKEY . @127.0.0.1 | grep -E '20326|38696'
# 2. Does end-to-end validation already fail?
dig +dnssec A cloudflare.com @127.0.0.1 | grep -E 'status:|flags:'
# 3. For Unbound: force a fetch of the current anchor, then restart.
unbound-anchor -a /var/lib/unbound/root.key && systemctl restart unboundIf command 1 does not return 38696, the resolver will not survive the cutover: that is the signal to act now, not on Sunday evening.
What comes next, and why not to lean on it
The first rollover, scheduled for 11 October 2017, was postponed two weeks before the date: of 11,692 resolver addresses reporting their trust anchors to the root servers, 577 still held only the old key. It happened on 11 October 2018 at 16:00 UTC, and ICANN’s review found “only a very few minor observable effects”. The second roll slipped too: the pandemic disrupted the in-person key ceremonies, and a replacement key generated in 2023 was abandoned because its hardware security modules were reaching end of support. KSK-2024 was generated on 26 April 2024 and has sat in the root since 11 January 2025, published but not yet signing.
The quietest risk arrives in January 2027, when KSK-2017 is published with its revoked bit set. In 2018, the switch itself only raised root DNSKEY queries at Verisign’s root servers from about 15 million to 75 million a day. The January 2019 revocation sent them to 1.15 billion a day — around 7% of the measured root traffic — and the flood only stopped when the old key was removed on 22 March. Nobody predicted it.
Verdict
If you operate validating resolvers — internal Unbound, BIND, Knot Resolver, or devices that validate — run the command-1 test on each one this week, especially those in read-only-filesystem containers or that have not been redeployed since 2024. If you rely on proprietary appliances — gateways, firewalls, DNS boxes — ask the vendor about KSK-2024 (key tag 38696) support before Sunday, because that is the population most exposed to a factory-frozen anchor. If you validate on a local forwarder — dnsmasq or an Unbound upstream of 8.8.8.8 — check your own anchor rather than assuming the upstream will save you: validation runs against your configuration, not theirs. The 11 October switch will almost certainly be a non-event for the majority — but for frozen resolvers it will be a total SERVFAIL, and the only remedy sits in the logs of a machine you may not have touched in years.