The Root Key Rollover Turns DNSSEC Readiness Into a Check Only Some Resolvers Can Answer

On October 11, 2026, the DNS root is scheduled to switch the key that signs its list of public keys, from KSK-2017 (key tag 20326) to KSK-2024 (key tag 38696). It is only the second time the root key signing key has changed, and ICANN’s warning to anyone running a DNSSEC-validating resolver is blunt: without the new key, “your network will experience total DNS resolution failures, cutting off Internet access for your users.” Cloudflare answered the obvious question, whether a given resolver is ready, with a browser test built on RFC 8509, a protocol that can only report on resolvers that implement it.

I tested how far that answer reaches. On October 6 I read the live root key set and ran the sentinel queries against ten public validating resolvers. Five answered the sentinel questions, and all five trust KSK-2024. The other five showed no consistent sentinel behavior, which the test can only report as inconclusive. The browser test is a useful confirmation where it works. Where it does not, the dependable check is the one ICANN gives operators: read the resolver’s own trust-anchor configuration for key tag 38696.

What changes on October 11

A validating resolver starts from a trust anchor, a root public key (or its fingerprint) that it already trusts. The root’s key signing key (KSK) signs the root’s DNSKEY set, and the zone signing key (ZSK) from that set signs the rest of the root zone. A resolver that does not trust the key that signs the DNSKEY set cannot validate anything beneath it. IANA’s rollover page states the plan in two sentences: “The successor key is scheduled to sign the zone; the current key will not sign the zone. Validating resolvers must have updated trust anchors to continue validating the root zone.”

The live key set, measured

I asked a.root-servers.net for the root DNSKEY set on October 6 at 19:28 UTC, using dnspython 2.8.0. For each key I computed the key tag and the SHA-256 DS digest, then compared both KSK digests with the DS values in IANA’s root-anchors.xml.

 key tag flags role         alg RSA bits  DS-SHA256 matches IANA root-anchors.xml?
    8763   256 ZSK            8     2048
   20326   257 KSK            8     2048  yes
   38696   257 KSK            8     2048  yes
   57780   256 ZSK            8     2048

RRSIG over the DNSKEY RRset:
  signed by key tag 20326 alg 8, inception 2026-10-01 00:00Z, expiration 2026-10-22 00:00Z, original TTL 172800

Four keys are published, both KSKs use RSA with SHA-256 and 2,048-bit moduli, and the set is signed by key tag 20326 only. The two KSK digests match IANA’s file, so the file and the live root agree on what KSK-2024 is. After the switch the signing key tag should change to 38696. That is the plan, not something I could measure on October 6, and the short script in the operator section lets you check it yourself.

Why a resolver needs the signer

To see how the failure works, I built trust-anchor sets from the public keys in IANA’s file and asked dnspython to validate the live DNSKEY set against each one.

The middle row has a practical consequence: you cannot rehearse a KSK-2024-only resolver against the live root before the switch, because the signature it needs does not exist yet. Readiness has to be checked by looking at what the resolver trusts, not by watching it fail early.

The dates, and one disagreement

ICANN’s May FAQ puts publication in February 2025, while IANA’s page and ICANN’s July blog both say 11 January 2025. I use January. The July 2024 date lines up with Cloudflare’s account that it added KSK-2024 to its resolver’s built-in trust anchors that month.

Why a missed key fails everything, and when it shows

The FAQ says a resolver without the new key “will treat responses signed under the new key as having been tampered with and will discard those responses,” which “will result in end users getting an error any time they look up a domain name.” It also keeps an exit open. If problems become widespread, the Root Zone Management Partners “could decide to reverse the changes” in what the FAQ calls a “back-out scenario,” and the timeline “may also be adjusted.” October 11 is the plan, not a guarantee, so a resolver that looks fine before the switch still deserves attention after it.

The failure would not arrive as one cliff. The signature on the DNSKEY set I measured carries an original TTL of 172,800 seconds, two days. A resolver holding a validated copy keeps answering until that copy expires, while one restarted or flushed after the switch starts with nothing cached. That is my reading of the numbers, not something the sources state: expect failures to show up staggered across the first two days, earliest on resolvers that restart, and watch the SERVFAIL rate across those days instead of the first hour.

How a resolver ends up without the key

ICANN reports that “more than 95 percent of reporting resolvers” have recognized and adopted KSK-2024. The same post tells administrators to “manually verify their configurations rather than assume automatic updates worked.” The gap between those two statements is where the risk sits.

Learned trust that does not survive

RFC 5011 lets a resolver learn the new key from the root itself, and it sets a hold-down: “The add hold-down time is 30 days or the expiration time of the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater.” That works only for a resolver that stays up, remembers what it has seen, and can write the result somewhere durable. Unbound’s manual spells out the cost for its RFC 5011 file: “The probes are run several times per month, thus the machine must be online frequently,” and “The file is written to when the anchor is updated, so the Unbound user must have write permission.” The manual adds that the Unbound user also needs write permission to the file’s directory, and that the file must sit inside the chroot if one is used. ICANN’s checklist compresses the same advice: confirm “that automatic trust updates are enabled and that your resolver has write permissions to its storage directory.”

Cloudflare’s 2018 experience shows one way this fails. It saw “resolvers lose their learned trust in the new key during software upgrades or moves between machines.” Its fix this time was to ship the key inside the software, so an updated resolver “has the new anchor available from startup.” By my reading, an ephemeral container or a read-only filesystem would defeat the remembering and writing parts, because it can lose what it learned at every restart. I did not test such a setup.

Software that never learns it

Not every resolver does RFC 5011. PowerDNS’s Recursor documentation says the Recursor “ships with the DNSSEC Root key built-in” and that “it has no support for RFC 5011 key rollover and does not persist a changed root trust anchor to disk.” For that software, what matters is the version you run or the trust anchors you configure, not how long the process has been up. dnsmasq’s manual documents --trust-anchor as the way to supply DS records for the root zone, and a search of that page finds no mention of RFC 5011. ICANN’s FAQ describes the route for software like this: “a publication stream trust anchor file will be available on the IANA website,” to be retrieved “when the resolver starts up, and when the KSKs in the DNSKEY RRset in the DNS root zone are changed.”

The IANA file lists KSK-2024 as key tag 38696, algorithm 8, digest type 2, digest 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16. In the syntax from dnsmasq’s manual, that is --trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16. I did not check which dnsmasq or PowerDNS releases already ship the key, so look at the version or file your package installs. ICANN’s blog lists root.key for both Unbound and PowerDNS Recursor, while PowerDNS’s own page describes a built-in key. For a default PowerDNS install, check the version and the trust anchors it is configured with.

The sampling gap

ICANN’s 95 percent describes resolvers that report. It cannot tell an operator whether their own resolvers are in the remainder. The 2018 precedent is the reminder: ICANN says the first rollover was “postponed for one year to allow more time for outreach” after data showed that many operators had not yet updated their systems. Only a check on the machine itself answers the question for that machine.

What the sentinel test can and cannot tell you

How the sentinel works

RFC 8509 defines two special leftmost labels. A resolver that implements it recognizes queries for root-key-sentinel-is-ta-<key-tag> and root-key-sentinel-not-ta-<key-tag>, where the tag is a decimal number zero-padded to five digits. If the key is trusted, the is-ta name gets its normal answer and the not-ta name gets SERVFAIL. If the key is not trusted, the two swap. The names can sit under any DNSSEC-signed domain that returns address records, and Cloudflare, which says it implemented the protocol in 1.1.1.1 ahead of the rollover, uses dnstest.dev. Cloudflare’s own commands query 1.1.1.1:

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

I ran the equivalent queries from Windows PowerShell 5.1, which has no dig, with the built-in resolver cmdlet:

foreach ($n in 'root-key-sentinel-is-ta-38696.dnstest.dev','root-key-sentinel-not-ta-38696.dnstest.dev') {
  try { $r = Resolve-DnsName -Name $n -Type A -Server 1.1.1.1 -DnsOnly -ErrorAction Stop
        "$n -> " + (($r | Where-Object {$_.Type -eq 'A'} | ForEach-Object {$_.IPAddress}) -join ',') }
  catch { "$n -> ERROR: " + $_.Exception.Message } }

root-key-sentinel-is-ta-38696.dnstest.dev -> 104.18.6.197,104.18.7.197
root-key-sentinel-not-ta-38696.dnstest.dev -> ERROR: root-key-sentinel-not-ta-38696.dnstest.dev : DNS server failure

An answer for the first name and a failure for the second is what RFC 8509 prescribes for a resolver that trusts the key.

Ten public resolvers, one afternoon

For each resolver I asked eight questions over UDP with TCP fallback: the signed name dnstest.dev, dnssec-failed.org, a public test domain that validating resolvers reject, and the is-ta and not-ta pairs for KSK-2024 (38696), KSK-2017 (20326) and an unused key tag (00001). A resolver that returns SERVFAIL for that test domain validates DNSSEC. One that answers both names of a pair does not implement the sentinel, because an implementation must fail exactly one name of each pair. The first pass ran at 19:29 UTC on October 6, followed by four more.

Three other resolvers fell outside the table. In the first pass, Mullvad’s 194.242.2.2 answered REFUSED to every query from this network, and Level3’s 4.2.2.2 resolved the broken test domain and so does not validate. The gateway resolver on my own network (a private address) implemented the sentinel and trusted both keys in all five passes. These results come from one network at one time of day, and anycast resolvers can differ by location.

So five of ten validating public resolvers gave the readiness test nothing to read. That is not evidence that any of them lacks the key. Cloudflare says plainly that an unsupported result “does not mean the new key is missing.” It means the test cannot confirm the key, and Google Public DNS and Quad9 are among the five it cannot confirm.

One name is not a verdict

Quad9 shows why the controls matter. In two of my five passes it returned SERVFAIL for not-ta-38696 while answering is-ta-38696, which is exactly what a resolver that trusts KSK-2024 would do. Every other sentinel name in all five passes, including the matching KSK-2017 and unused-tag pairs, was answered, so the SERVFAIL was noise and not a sentinel. A tester that asked only the two 38696 names would have recorded a pass. RFC 8509 anticipates this: “Note that other issues can also cause a resolver to return SERVFAIL responses, and so the sentinel processing may sometimes result in incorrect or indeterminate conclusions.” Cloudflare’s page guards against it with controls, including a sentinel query for the current root key. If you script the test yourself, do the same.

Browsers and forwarders

The browser test adds two more limits. Cloudflare notes that it checks the resolver your browser uses, “which may be affected by Secure DNS or a VPN.” And RFC 8509 observes that a non-validating resolver with a single forwarder “will presumably mirror the capabilities of the forwarder’s target resolver.” In an enterprise, the answer therefore describes whichever validating resolver sits at the end of the chain, which may not be the one you meant to test.

If you run your own resolver, the sentinel may be built in. Unbound’s manual lists root-key-sentinel with a default of yes, and BIND’s reference says the option “Controls whether BIND 9 responds to root key sentinel probes,” also defaulting to yes. PowerDNS’s DNSSEC page and dnsmasq’s manual never mention the sentinel, which leaves the configuration check as the only method I can point to for them.

A check that does not depend on the sentinel

ICANN’s rollover page asks operators to verify that KSK-2024 (key tag 38696) is present in their trust-anchor configuration and not to assume automatic updates succeeded. Its blog names the files to read.

That gives four steps. First, find the anchor: the file or configuration should show key tag 38696, or the digest above. Second, confirm the resolver can keep what it learns: it must be able to write its state and must not be rebuilt from a baked-in file on every restart. Third, if the resolver supports the sentinel, run the pair with controls as in the table above. Fourth, after the switch, confirm which key the root is using and watch resolution failures through the two-day cache window. This script, which I ran as written on October 6, does the root half of the last step:

import dns.message, dns.query, dns.dnssec, dns.name, dns.rdatatype, dns.rdataclass

q = dns.message.make_query(".", "DNSKEY", want_dnssec=True, use_edns=0, payload=4096)
r = dns.query.udp(q, "198.41.0.4", timeout=4)  # a.root-servers.net
keys = r.find_rrset(r.answer, dns.name.root, dns.rdataclass.IN, dns.rdatatype.DNSKEY)
sigs = r.find_rrset(r.answer, dns.name.root, dns.rdataclass.IN, dns.rdatatype.RRSIG, dns.rdatatype.DNSKEY)
print("published KSKs:", sorted(dns.dnssec.key_id(k) for k in keys if k.flags == 257))
print("DNSKEY set signed by:", sorted({s.key_tag for s in sigs}))

published KSKs: [20326, 38696]
DNSKEY set signed by: [20326]

After the switch, the second line should read [38696]. The script needs only pip install dnspython.

What comes after the switch

Switching signers is not the end of the sequence. The FAQ schedules KSK-2017’s removal from the root zone for the first quarter of 2027, and the rollover is also rehearsal for a bigger change. ICANN’s February 2026 proposal would move the root from RSA with SHA-256 to ECDSA P-256 using “a common double-signing approach for DNSSEC transitions,” after shrinking the RSA zone signing key from 2048 to 1536 bits, with milestones running from a new ECDSA key in 2027 to retiring the replaced KSK in 2030. Cloudflare adds that a post-quantum root KSK would need yet another rollover, and that 1.1.1.1 already validates ML-DSA-44 signatures.

Each of those changes needs the same two things this one does: software that learns a new anchor, and a way to confirm that it did. The sentinel supplies the second only where it is implemented, which is why Cloudflare closes by writing, “We encourage DNS providers and resolver developers to support RFC 8509 trust anchor sentinels.” The same pattern, a key change that is really an inventory problem, appears in Microsoft’s 2026 Secure Boot certificate rollover, and the idea of auditing a key exchange one hop at a time is the subject of our look at Cloudflare’s post-quantum visibility logs.

The practical reading

For someone who only uses a public or ISP resolver, there is little to do. Cloudflare says that “Most website operators do not need to make any changes for this rollover,” and ICANN’s request is aimed at people who run validating resolvers. For those operators the question is an inventory one: which of your resolvers validate, where does each keep its trust anchor, does that location survive a restart, and can you show key tag 38696 in it today? The sentinel can answer that for about half of the public resolvers I tried. For the rest, and for anything inside your network, the file is the evidence.