The DNS Root Changes Its Key on Sunday. A Resolver That Still Trusts Only the Old One Stops Resolving Everything.

On Sunday, October 11, the DNS root zone’s DNSKEY set will be signed only by KSK-2024, key tag 38696, and KSK-2017, key tag 20326, stops signing after eight years. For nearly everyone this is invisible: the new key has been published in the root since January 2025, current resolver software ships with it, and ICANN’s July figure was that “more than 95 percent of reporting resolvers” already trust it. For the remainder, the failure mode is total. As ICANN’s Roy Arends put it, “If your DNSSEC-validating resolver does not have KSK-2024 configured by this date, your network will experience total DNS resolution failures, cutting off Internet access for your users.”

Hosting providers are in range in two ways. The sharper risk is not the central resolver, which is usually current, but the per-server one: an Unbound instance on a mail host doing DNSBL lookups, a frozen appliance, or a VM image with a trust anchor copied in years ago and no write permission on the key file. And customers behind someone else’s stale resolver will report the host’s sites as down from Sunday onward, as each such resolver’s cached copy of the root keys expires and every name under every top-level domain fails validation at once. The check takes a minute; the sentinel test below answers it without reading a config file.

Key facts

• The date: October 11, 2026, when “the root zone will begin using only KSK-2024.” The key tag to look for is 38696. KSK-2017, tag 20326, is scheduled for revocation in January 2027 (ICANN’s operator notice gives January 11) and remains visible in the root zone until then.
• The run-up: KSK-2024 has been in the root’s DNSKEY set since January 11, 2025 and became eligible for automatic adoption under RFC 5011 after the 30-day hold-down, in February 2025. ICANN announced the October date on May 20.
• Readiness: ICANN and Verisign report the adoption curve “nearly mirrors” 2018, with the incoming key above 95 percent of resolvers that signal their trust anchors under RFC 8145. The resolvers that do not signal are the unknown.
• The failure: a validating resolver that trusts only KSK-2017 returns SERVFAIL for every signed name and, because the root itself fails, for everything else too. Cloudflare’s phrasing: its users “may be unable to reach websites under any top-level domain.” The root’s DNSKEY set carries a 48-hour TTL, so a stale resolver breaks when its cached copy expires, any time from Sunday to Tuesday, and answers it already holds keep serving until their own TTLs run out.
• The deadline: RFC 5011 automatic adoption works only while the new key is published in a set signed by a key the resolver already trusts. From October 11 that is no longer true, so a resolver that has not picked up KSK-2024 by then cannot do so on its own; the repairs are a manual anchor edit, a software upgrade or, as a first response, switching validation off.
• The test: RFC 8509 sentinel names. A resolver that trusts the new key resolves root-key-sentinel-is-ta-38696 and fails root-key-sentinel-not-ta-38696; a stale one does the reverse, until Sunday; after the change a stale resolver fails both. Cloudflare hosts a browser version at dnstest.dev/ksk-2024.

What Changes on October 11 and What Does Not

The rollover is the second in the root’s history and has been staged in the open since 2024. The new key’s public half entered the root zone on January 11, 2025, alongside KSK-2017, so that resolvers implementing RFC 5011 could observe it for the required 30 days and add it as a trust anchor on their own; Verisign’s Duane Wessels and ICANN’s Arends date that threshold to February 10, 2025. Sunday’s step is the signing change: from then on the root’s DNSKEY RRset carries a signature only from KSK-2024. The old key stays published, in APNIC’s description, “until early 2027,” and, as Cloudflare lays out the sequence, ICANN then revokes it, removes it and destroys the private half.

Nothing changes for zones below the root, for authoritative servers, or for anyone whose resolver trusts the new key. Cloudflare added KSK-2024 to 1.1.1.1’s built-in trust anchors in July 2024 and says its DNS and Gateway customers “do not need to take any action.” The same holds for any resolver on software released in the past two years, unless someone pinned a trust anchor by hand. What closes on Sunday is the automatic route: RFC 5011 lets a resolver add a new key only after seeing it in a DNSKEY set signed by a key it already trusts, and from October 11 the root’s set is signed only by the key a stale resolver lacks. A resolver started after that date from an old root.key, an old VM template, a container image or a snapshot cannot adopt KSK-2024 by itself, and one started after September 11 has not finished its 30-day hold-down either.

Why the Signalling Number Is Not the Whole Picture

The confidence figure comes from RFC 8145, under which resolvers tell the root servers which trust anchors they hold. Verisign’s measurement shows essentially every signalling resolver trusting KSK-2017, about 3.5 percent still carrying KSK-2010 from the last rollover, and KSK-2024 above 95 percent after roughly 500 days, on a curve “nearly identical” to 2018’s. The population that signals is larger than it was then, which is the good news. The bad news is structural: a resolver that does not implement RFC 8145 cannot be counted, and that class overlaps heavily with old builds and manual configurations, which is exactly where a missing key would be.

The 2018 precedent is reassuring but not a guarantee. ICANN said the first rollover “has been completed with minimal disruption of the global Internet,” with “few issues” that “none suggested a systemic failure.” SIDN Labs, watching from more than 500 Dutch vantage points and 10,000 RIPE Atlas probes, saw “below 1%” of resolvers with validation problems and “more than 99%” up to date after 48 hours. That rollover had been postponed by a year because readiness data looked worse than it does now.

The Checklist for a Host Running Its Own Resolver

ICANN’s advice is to verify rather than assume: “Do not assume automatic trust-anchor updates succeeded. If the key is missing, confirm that automatic updates are enabled and follow your resolver vendor’s guidance to update the trust anchors.” The file to inspect depends on the software: bind.keys for BIND, root.key for Unbound, root.keys for Knot Resolver; PowerDNS Recursor carries the root key inside the binary. In every case the entry to find carries key tag 38696.

The quickest test does not need the file. From any machine that uses the resolver in question:

dig root-key-sentinel-is-ta-38696.dnstest.dev. A
dig root-key-sentinel-not-ta-38696.dnstest.dev. A

A ready resolver answers the first and returns SERVFAIL on the second. A stale one does the opposite. A resolver that answers both is either not validating or does not support the sentinel mechanism, which is a separate conversation. The test is diagnostic only until Sunday: once the root is signed by KSK-2024 alone, a stale resolver fails both names, which is indistinguishable from an outage. Cloudflare’s page at dnstest.dev/ksk-2024 runs three sentinel queries from a browser and adds a control pair for a correctly and an incorrectly signed name.

For Unbound, the trust anchor is maintained by unbound-anchor and tracked at runtime through the auto-trust-anchor-file directive. The manual’s own example is:

unbound-anchor -a "/usr/local/etc/unbound/root.key"
grep 38696 /usr/local/etc/unbound/root.key

The path varies by distribution, and the manual is explicit that the Unbound user must have write permission on the file and its directory; without it the updated key is not written to disk and does not survive a restart. Running unbound-anchor as root leaves a root-owned file that Unbound cannot update later. That permission problem is the most common way a correctly configured resolver ends up stale.

For BIND, ISC’s guidance since the first rollover has been to let named manage the keys itself, with dnssec-validation set to auto or a managed-keys clause, and to check what it currently trusts with:

rndc managed-keys status
rndc secroots

The output lists the trusted keys by tag; note that rndc secroots writes to named.secroots on disk unless called as “rndc secroots -“, which prints to the terminal. A trusted-keys clause, the static form, does not update itself and must be edited by hand from ISC’s published bind.keys. PowerDNS Recursor is a different case: it “ships with the DNSSEC Root key built-in,” has, in its own documentation, “no support for RFC 5011 key rollover,” reads no root.key unless one is configured, and lists its anchors with “rec_control get-tas”; its default mode, process, validates only for clients that set the DO or AD bit, so a stale Recursor is an old binary, and the fix is an upgrade. dnsmasq, common on small hosts and in Pi-hole, is static too: its trust anchors are given with the trust-anchor option and nothing updates them automatically.

What Customers Behind a Stale Resolver Will See

The symptom is not a slow site but a dead one: no name resolves, including the host’s own control panel, mail and nameservers, while the same sites open fine from a phone on mobile data. It does not arrive on a schedule. Each stale resolver breaks when its cached root key set, held for up to 48 hours, expires and is refetched, and names it had already validated keep answering until their own TTLs run out, so support desks should plan for Monday and Tuesday, not only Sunday. A cross-check against 1.1.1.1 or 8.8.8.8 settles a ticket in seconds. The first-responder move at the customer’s end is to switch validation off or point at a public resolver, and the repair is a manual trust anchor edit or a software upgrade, because after Sunday the automatic route is closed. Hosts that run a resolver for their customers’ servers have until their own cached root keys expire, at most 48 hours after the change, and the earlier check costs a minute.

ICANN’s figures are for resolvers that signal their trust anchors under RFC 8145; the share of non-signalling resolvers that are ready is not measured. Distribution file paths for Unbound and BIND differ from the upstream defaults quoted above. Neither ICANN nor Cloudflare was contacted for this article.