The root KSK rollover swapped the key at the top of the DNSSEC chain, and what matters now is whether each of your validating resolvers swapped with it. IANA's Trust Anchors and Rollovers page lists KSK-2024 (key tag 38696) as signing since 2026-10-11, with KSK-2017 (key tag 20326) no longer signing the root zone.
IANA's announcement of 11 October states that the root zone began using a new KSK on that date, key tag 38696, replacing the previous key. That is IANA's statement of the event, not a query of my own.
That is the scheduled state. Whether it is your state is a separate fact, and for most estates nobody has recorded it. Verisign's July data, as APNIC reports it, put roughly 90% of reporting resolvers at KSK-2024, while APNIC's own early-October measurement found about 70% of RFC 8509-capable test results reporting it trusted, with several ISPs under 10%. Those are different populations measured different ways, and neither describes your resolvers. This post is a method for producing that description: three kinds of evidence per resolver, kept on one worksheet.
How a Root KSK Rollover Breaks Validation
A validating resolver does not discover trust; it is configured with it. The trust anchor is the one input DNSSEC cannot supply for itself. Everything beneath it is derived: the KSK signs the root DNSKEY RRset, that RRset publishes the zone-signing key, the ZSK signs the DS records for the TLDs, and each TLD vouches for the zones below it. A resolver validates an answer by walking that chain upward until it reaches a key it was told to trust.
KSK-2024 has been published in the root DNSKEY RRset since January 2025. What the root KSK rollover changed on 11 October is the signer. The RRset is now signed by KSK-2024, and IANA lists KSK-2017 as no longer signing. A resolver whose trust anchors contain only KSK-2017 now receives a DNSKEY RRset signed by a key it was never told to trust. It cannot complete the chain, treats the data as bogus, and returns SERVFAIL. The algorithm did not change, so this is trust-anchor state and nothing else.
The failure is not limited to signed domains. To answer for an unsigned name, a validating resolver must still prove that no DS record exists at the parent, and that proof rests on the same chain. The expected symptom is broad SERVFAIL for that resolver's clients, signed and unsigned names alike.
Timing is where operators get misled. A resolver caches the DNSKEY RRset and its signature, and answers validated against the old signature stay usable until that cached data expires. The symptom therefore reaches different resolvers at different moments and can trail the switch-over. The size of the window is not a constant to quote. It is in the root's response, as the TTL on the DNSKEY RRset and the validity period of its RRSIG.
I am not reporting an outage. This is what a validating resolver without KSK-2024 is expected to do. Whether any resolver you run is in that state is what the rest of this post establishes.
Where the Trust Anchor Doesn't Update Itself
RFC 5011 is why most resolvers needed no operator during the root KSK rollover. A resolver that supports it watches the root DNSKEY RRset, sees a new KSK appear, holds it for at least 30 days, and then adds it to its trust anchors without human action. KSK-2024 has had far longer than that, so a resolver running continuously, with state it can write and persist, has trusted it since early 2025.
The exposure is every resolver that doesn't meet those conditions. That is an inventory problem, not a DNS problem.
Resolvers that don't self-update:
- Pinned anchors — a static anchor file or configuration statement carrying only KSK-2017, never touched because it never had to be
- Restored and cloned images — a resolver recovered from a snapshot returns with the trust state it had when the snapshot was taken, and one that was off or restored before it finished adopting KSK-2024 can no longer validate the RRset it would need to learn the key
- Appliances and embedded resolvers — firmware that ships a fixed anchor, where the update path is a firmware release
- Stateless containers — a resolver that can run RFC 5011 but discards its managed state on restart returns to whatever the image shipped, every time
- Forwarding chains — a forwarder that trusts the AD bit from an upstream validator inherits that upstream's anchor state, so a failure at a resolver you don't run still lands in your tickets
Resolvers built from images and modules inherit whatever trust state the image carried. That makes this as much a modern infrastructure and IaC problem as a DNS one: the stale anchor is a baked artifact, and drift detection rarely tracks it.
⚠ Common mistake: Reading the anchor file as the resolver's state. A file on disk records what the resolver was configured to load. It does not prove what the running process loaded, and a file edited after the last restart proves nothing at all.
The scheduled revocation of KSK-2017 on 11 January 2027, and its removal on 22 March 2027, are the second half of the exposure. Both are IANA schedule dates, not yet events. A resolver following RFC 5011 learns of the revocation by watching the root. A pinned anchor never does and keeps trusting a retired key. That is revocation scoped at the trust root, and it carries the property the revocation unit argument describes: it reaches only the verifiers that are still watching.
Three Results, Not One: Configured, Runtime, Behavioral
Marking the root KSK rollover done because the date passed is the closure error the architecture of premature closure names. This is not another row in that table: the change is external, you ran no remediation, and the question is whether your resolvers absorbed it.
Record three results per resolver. Each answers a different question and none substitutes for the others.
| Result | Question | Evidence | What it can't prove |
|---|---|---|---|
| Configured | Is KSK-2024 (tag 38696) in the trust-anchor source? | The anchor file or configuration for your software: BIND bind.keys (initial-ds 38696) or a trust-anchors statement, Unbound's auto-trust-anchor-file, Knot Resolver's root.keys
|
That the running process loaded it |
| Runtime | Has the running resolver loaded it? | BIND rndc managed-keys status; PowerDNS Recursor rec_control get-tas; where no command lists anchors (Unbound 1.19 has none), compare process start or reload time to the anchor file's modification time |
Anything about validation behavior |
| Behavioral | Does the resolver validate using it? | The RFC 8509 sentinel test; a known-signed name returned with the ad flag set |
Which anchor produced the result, or whether a forwarder answered instead |
The RFC 8509 sentinel test is the behavioral check, and it is a three-query test. A client queries a deliberately bogus name, then two names built from the key tag, root-key-sentinel-is-ta-38696 and root-key-sentinel-not-ta-38696, as the leftmost label under a DNSSEC-signed test zone. A sentinel-aware validating resolver that trusts key 38696 answers the is-ta name and returns SERVFAIL for the not-ta name. One that does not trust it does the reverse. The bogus name must SERVFAIL; if it answers, something in the path is not validating. Some combinations, such as SERVFAIL on the bogus name and an answer on not-ta, are indeterminate when several resolvers sit behind one address. RFC 8509 §4.3 treats those as unreliable. Record them as indeterminate, not as a pass or a fail.
Three cautions apply. Sentinel support is not universal, so a non-answer can mean unsupported rather than untrusted. A forwarder in front changes which resolver you tested. And a pass is evidence for the path that carried the query, not for every resolver you run.
Diagnostic: "Which key does this resolver trust right now, and what did it do to prove it?"
Telling a Trust-Anchor Failure From Ordinary SERVFAIL
A root trust-anchor failure looks like every other SERVFAIL until you change one variable. Run the failing query against the suspect resolver with checking disabled (dig +cd). If it answers with +cd and fails without it, validation is failing, not reachability. Then query an unsigned name. Broad failure across signed and unsigned names with +cd succeeding points to the top of the chain, since an expired signature or DS mismatch normally fails one zone. Neither test proves a root trust-anchor failure on its own. The stronger diagnosis comes from the sentinel result, the direct anchor evidence from the table above, and a comparison against a second validating resolver known to hold KSK-2024. Read the Extended DNS Error (RFC 8914) where your resolver returns one.
Layered triage, such as the five phases in It's Not DNS (It's MTU), localizes a failure by path. A root-anchor failure isn't a location in that stack: every network-layer test can pass while the resolver still returns SERVFAIL, so the order of checks above is a trust test, not another triage ladder. The same separation holds for failover. A test that measures when traffic actually moves, the question DNS failover testing works through, is a caching question. This one is a trust question, and a resolver can pass the first while failing the second.
The Resolver Evidence Worksheet
The root KSK rollover leaves one row per validating endpoint, forwarders included. The columns are the record you will want to hand someone later:
| Field | What goes in it |
|---|---|
| Endpoint | Resolver or forwarder address, and what depends on it |
| Software and version | Needed to interpret the commands and sentinel behavior |
| Validation location | This host, or an upstream |
| Anchor management | RFC 5011 managed, static file, firmware-embedded, image-baked |
| Configured / Runtime / Behavioral | Three separate results, each with its evidence and query path |
| Timestamp and owner | When it was checked and who is accountable for the row |
Score each row PASS only when all three results are recorded. Anything unchecked is a FAIL until evidenced. Re-run the worksheet at the KSK-2017 revocation and removal dates, because those are the points at which pinned anchors diverge from managed ones.
Download the Root KSK Rollover Resolver Evidence Worksheet: spreadsheet or PDF — the per-resolver record used in this post, with a command reference by software.
Architect's Verdict
A root KSK rollover is scheduled, announced and documented, which is why it fails quietly. Nobody opens an incident for an event that went to plan, and the plan was never what needed to succeed. The root signed with the new key. Whether your resolvers trust it is a separate fact, held in places that are not treated as configuration.
The real problem is where resolver trust state lives. It sits in images, firmware, a state directory that may not persist, and a forwarder chain owned by someone else. None of those appear in an inventory under the name trust anchor, so the question of which key a resolver trusts has no owner until the day it matters.
A rollover is finished when each resolver can show which key it trusts and a test that proves it. Everything before that is a calendar entry.
Additional Resources
- Modern Infrastructure & IaC Architecture — the pillar hub for image- and module-built estates, where stale resolver trust state gets baked in and goes untracked.
- Rotating Credentials Is Not Revoking Them. The Revocation Unit Decides Whether You Can. — trust-root revocation reaches only the verifiers still watching, the property the scheduled KSK-2017 revocation shares.
- The Architecture of Premature Closure — the signal-fired, state-unverified pattern; this post differs because the change is external and no remediation of yours ran.
- It's Not DNS (It's MTU): Debugging Kubernetes Ingress — layered path triage that localizes failures by network location, the contrast case for a trust-state failure.
- Why Your DNS Failover Didn't Actually Fail Over — traffic-movement timing across caching layers, a different question from resolver trust.
- IANA: Trust Anchors and Rollovers and IANA's 11 October announcement — the signing-since date for KSK-2024, the announcement that the root zone began using it, and the scheduled KSK-2017 revocation and removal dates.
Originally published at rack2cloud.com
Top comments (0)