KSK roll 2026 check: is the resolver you run ready?
Step 1: check what your resolver trusts#
Check the trust anchor your resolver stores, not what it says it validates. The sentinel test on ksk-roll-2026 asks the second question; this is the first.
| Resolver | Updates its anchor by itself (RFC 5011) | Where to look |
|---|---|---|
| BIND 9 | Yes, with dnssec-validation auto; | rndc managed-keys status: 38696 listed as trusted |
| Unbound | Yes, with auto-trust-anchor-file | the anchor file: 38696 with state VALID |
| Knot Resolver | Yes, by default | the keyfile it keeps: 38696 listed |
| PowerDNS Recursor | No, the root key is built into the binary and moves only on upgrade (docs) | dig trustanchor.server CH TXT (needs recursor.allow_trust_anchor_query): 38696 listed |
A key the resolver has seen but not yet trusts is in its 30-day hold-down (RFC 5011 section 2.4.1). Only trusted counts on 2026-10-11. The hold-down runs per resolver, so a box rebuilt from an old image starts it again from day 0.
Step 2: compare against the source#
Compare it with IANA's trust anchor file, the one normative source, and with the root itself.
curl -s https://data.iana.org/root-anchors/root-anchors.xml<KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00">
<KeyTag>20326</KeyTag>
...
<KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00">
<KeyTag>38696</KeyTag>
...Your resolver must trust 38696 before 2026-10-11. The root publishes both keys today; the two with flags 257 are the KSKs:
Asks the root for its public keys, which is what the roll replaces.
dig @1.1.1.1 . DNSKEYGO NOERROR and two keys with flags 257, 20326 and 38696
NO GO SERVFAIL
DO resolver operator: Fix the trust anchor, step 3
Step 3: fix it if it is already broken#
Fix it in this order if every validated lookup is SERVFAIL after the roll and step 1 shows 38696 missing. The first two come from ICANN's 2018 rollover review, section 3.4.
- Stop the outage. Turn validation off, or set a negative trust anchor for the root (RFC 7646). Both drop DNSSEC protection for everyone behind the resolver. An NTA expires by itself: "The lifetime SHOULD NOT exceed a week" (RFC 7646 section 4).
- Install 38696 from root-anchors.xml, where your resolver reads its anchors. Its own documentation names the place.
- Turn validation back on and run the test on ksk-roll-2026 until it says Ready.
The dates#
| Date | What happens |
|---|---|
| 2025-01-11 | 38696 published in the root |
| 2025-02-10 | earliest a resolver trusts it, after the 30-day hold-down (RFC 5011 section 2.4.1) |
| 2026-10-11 | 38696 signs alone; 20326 stays published |
| 2026-10-11 +48h | failures show as cached root key sets expire |
| 2027-01-11 | 20326 scheduled to be published with the REVOKE bit |
| 2027-03-22 | 20326 scheduled to be removed from the root zone |
Sources: IANA's timeline at iana.org/dnssec/files and ICANN's root zone KSK rollover FAQ (PDF, 2026-05-22), p.3.
See also#
- dnssec: how the trust chain works
- dnssec-troubleshooting: when the answer is already
SERVFAIL