On Sunday, October 11, 2026, the DNS root zone changes the key that signs its key set. KSK-2024 (key tag 38696) starts signing and KSK-2017 (key tag 20326) stops, after eight years in the job. It is only the second time the root key signing key has been replaced since the root was signed in 2010. Any DNSSEC-validating resolver that does not already trust the new key will stop resolving names: all of them, signed or not.
Most resolvers picked up the new key automatically in February 2025 and will not notice the change. The ones at risk are resolvers whose trust anchor was frozen at some point: baked into an old container image, pinned by hand in a config file, or sitting inside an appliance nobody has updated. This post explains what happens at the switch, which setups fail, what the failure looks like from an application, and how to check a resolver before Sunday.
One signature at the top of the tree is replaced
DNSSEC validation is a chain. Your zone's keys are vouched for by a DS record in the parent zone, the parent's keys by a DS record in the root, and the root zone's records are signed by the root zone signing key (ZSK), which Verisign rotates every quarter. The ZSK is in turn signed by the key signing key. Nothing signs the KSK. A resolver trusts it because a copy of it, the trust anchor, is stored in the resolver's own configuration.
That locally stored copy is the weak point of the design. Every other key in DNSSEC can be replaced by publishing new records. Replacing the root KSK means changing a setting inside every validating resolver on the internet, and nobody has a list of them.
Eight years on one key, twenty-one months of notice
The first KSK, created in 2010, was supposed to be rolled after five years. The roll was scheduled for October 11, 2017, then postponed two weeks before the date: of 11,692 resolver addresses reporting their trust anchors to the root servers, 577 still had only the old key. It happened on October 11, 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 April 26, 2024, and has been in the root zone since January 11, 2025, published but not yet signing anything.
RFC 5011 works until the resolver cannot remember
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 trust anchors and writes that to disk. For a resolver that was running on January 11, 2025, the timer expired on February 10, 2025.
The write to disk is where it fails without telling anyone. A resolver in a container with a read-only filesystem, or one redeployed from an image every week, restarts with whatever anchor was baked into the image and starts the 30 days again. It never gets to the end. Current releases of Unbound, BIND and Knot Resolver ship both keys built in, 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. And a local forwarder is exposed if it validates itself: dnsmasq with DNSSEC enabled, or Unbound sending queries to 8.8.8.8, still checks signatures against its own anchor, whatever Google trusts.
How many resolvers are in this state? The sources disagree. Verisign's Duane Wessels and ICANN's Roy Arends report that more than 95% of resolvers announcing their trust anchors to the root servers (RFC 8145) now list KSK-2024, in line with the 2018 roll at the same stage. Oddly, about 3.5% of them still list KSK-2010, a key revoked in 2019. Geoff Huston at APNIC measured from the user side in April 2026 with a different technique and found under 20% of users behind validating resolvers reporting the new key as trusted. He called it "certainly not the result that we had anticipated" and notes that the signal is noisy. Neither method can see a resolver that reports nothing, which is exactly what a frozen appliance does.
Failure arrives as SERVFAIL, spread over 48 hours
A resolver holding only KSK-2017 does not break at the moment of the switch. The root DNSKEY set has a 48-hour TTL, so each resolver keeps validating with its cached copy until that expires, then fetches the new one, fails to verify the signature, and marks the root as bogus. Those 48 hours are an upper bound: a resolver that caps how long it caches records fails sooner, and Unbound's default cap is one day. In 2018, ICANN put the limit at October 13 for a roll on October 11. Expect stragglers to fall over through Tuesday the 13th this time as well, and immediately if someone restarts them.
From that point the resolver answers SERVFAIL to everything. Unsigned domains fail too, because proving that a zone is unsigned requires a validated path from the root. Applications never see the word DNSSEC. They get getaddrinfo failures, timeouts and retries, while names that were cached a minute ago keep working. It looks like a flaky network.
The .de outage of May 5, 2026 showed the pattern at scale. A bug in DENIC's signing software generated three key pairs instead of one during a routine rollover, only one was published, and roughly two thirds of the zone's signatures stopped validating at about 19:30 UTC. Cloudflare saw SERVFAIL climb steadily for three hours as caches drained, while retries pushed query volume up. At 22:17 UTC it switched off validation for .de on 1.1.1.1 with an override that works like a negative trust anchor.
There is a difference that matters on Sunday. In May the publisher was wrong, every validating resolver failed together, and the big operators could each apply the same workaround. On October 11 the root will be right and a stale resolver will be wrong on its own. Nobody upstream can fix that for you.
Checking a resolver takes about a minute
First find out whether the resolver validates at all. Ask it for a signed name and look for the ad flag in the header (replace 192.0.2.53 with the resolver's address):
dig @192.0.2.53 ietf.org +dnssec | grep ';; flags'
;; flags: qr rd ra ad; ...No ad flag means no validation, and the rollover cannot hurt that resolver (it is also not protecting anyone). The flag alone is not proof, though: a forwarder that does not validate can pass along the ad flag set by its upstream, as dnsmasq does with proxy-dnssec. If the flag is there, look for key tag 38696 in the trust anchor store. A forwarder with no anchor store at all is relaying someone else's validation. Paths vary by distribution.
# Unbound: the line for 38696 should say state=2 [ VALID ]
grep 38696 /var/lib/unbound/root.key
# BIND 9.11 and later: keyid 38696 should show "trusted since"
rndc managed-keys status
# Knot Resolver
grep 38696 /var/lib/knot-resolver/root.keys
# PowerDNS Recursor: both 20326 and 38696 should be listed
rec_control get-tasOn Unbound, a state of ADDPEND means the hold-down timer is still running, which a week before the roll is a failing grade. Run the check inside the container or appliance that serves production traffic, then restart it and run it again. An anchor that disappears on restart is the failure described above.
If you only use a public resolver such as 1.1.1.1, 8.8.8.8, 9.9.9.9 or Wikimedia's, with no validating forwarder in between, the anchor is their operator's job and there is nothing for you to configure. Authoritative servers are not involved either. The rollover changes nothing in your own zone or in the transport your name servers answer on.
What to watch on Sunday, and again in January
Graph the SERVFAIL rate per resolver and keep watching until Tuesday evening. 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 down and that will take a while, turning validation off for an hour is a defensible stopgap. Cloudflare made the same call for .de.
ICANN has a way back as well. Its FAQ describes a "back-out scenario" in which the root zone partners return to the previous state if problems become widespread. For the first roll the trigger was 0.5% of internet users affected 72 hours after a change. We could not find the 2026 threshold in the public documents, so do not plan around being rescued.
The quieter risk comes 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 a day to 75 million. The revocation in January 2019 sent them to 1.15 billion a day, around 7% of the root traffic Verisign measured, and the flood only stopped when the old key was removed on March 22. Nobody had predicted it.
When a resolver you do not recognize shows up in an incident on Sunday, the first question is whose it is. Ipregistry returns the network and organization behind any IP address, which tells you quickly whether a failing upstream belongs to your ISP, a cloud provider or a public DNS service. You can try the API with 20,000 free lookups to get started.
Keep users in the loop Ship release notes that get read. Try Noticeable