KSK roll 2026 reference

This is the reference behind ksk-roll-2026, which is the two tests and the live board on one screen. Everything here is detail: the timeline and the sources, the prestaged root key set as one query shows it, the sentinel test in full with its one false positive, what to verify per resolver software, the fix when it is already broken, and what the 2018 roll actually showed.

$ dig @1.1.1.1 . DNSKEY

What happens on October 11#

The root zone has two Key Signing Keys published today: KSK-2017 (key tag 20326, the key that has anchored the root since the 2018 roll) and KSK-2024 (key tag 38696). On 2026-10-11, KSK-2024 becomes the sole signer of the root key set. KSK-2017 stays published but stops signing, and it stays published for a reason: it has to be republished with the REVOKE bit set so that an RFC 5011 tracker retires it deliberately rather than merely losing sight of it. ICANN's 2018 review, p.13: "If a validating resolver that follows RFC 5011 sees the old key with the revoke bit set, that resolver will never trust the old key again."

Revocation and removal are two distinct steps, not one date. In the 2018 roll they were ten weeks apart: KSK-2010 was revoked on 2019-01-11 and removed from the zone on 2019-03-22.

Sources: the IANA rollover timeline table at iana.org/dnssec/files and the normative trust anchor file root-anchors.xml. The phase list is in ICANN's root zone KSK rollover FAQ (PDF, 22 May 2026), p.3, which gives the revocation phase as a quarter and not a day: "Phase F: Revocation (Q1 2027) - KSK-2017 is removed from the root zone." IANA's table currently lists no revocation event at all, only the three rows above. The exact cutover time in UTC has not been published yet; the 2018 roll cut over at 1600 UTC.

The mechanics of why a trust anchor matters at all are on dnssec: validation walks DS to DNSKEY to RRSIG from the root down (RFC 4033, RFC 4034, RFC 4035), and the walk starts from the root key your resolver has decided to trust. Change that key, and every resolver on the Internet has to already trust the new one.

See the prestaged state, live#

You do not have to take the timeline's word for it. The root key set is public, and one query shows exactly where the roll stands today.

1. Who we asked: 1.1.1.1 over DoH (dig +https, so no port 53 middlebox could touch the answer), for the root's DNSKEY set with signatures. Captured 2026-08-18. Keys are truncated here for width, and the TTL counts down from 172800, so your numbers will differ in the boring places.
2. What came back: four records. One ZSK, both KSKs, and one signature:

dig +https @1.1.1.1 . DNSKEY +dnssec +multiline

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39637
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
.  2715 IN DNSKEY 256 3 8 (
        AwEAAeCYD6Z7WWKVLeuWgowKP+3g ... j4wIy5k=
        ) ; ZSK; alg = RSASHA256 ; key id = 57780
.  2715 IN DNSKEY 257 3 8 (
        AwEAAaz/tAm8yTn4Mfeh5eyI96WS ... UTV74bU=
        ) ; KSK; alg = RSASHA256 ; key id = 20326
.  2715 IN DNSKEY 257 3 8 (
        AwEAAa96jeuknZlaeSrvyAJj6ZHv ... fKC73PYc=
        ) ; KSK; alg = RSASHA256 ; key id = 38696
.  2715 IN RRSIG DNSKEY 8 0 172800 (
        20260831000000 20260810000000 20326 .
        V78PtBnjcahYNt6ZWnzGlM+EExU9 ... IZxCd4A== )

1. Verdict: both KSKs are published, and the RRSIG names 20326 as its signer. Both keys published, the old one still signs: that is the prestaged state. On 2026-10-11 the signer field in that RRSIG starts saying 38696, and that one-number change is the entire roll. The chain visualizer draws this same key set at the root of every walk, so you can watch the handover happen without typing anything.

Will your resolver break?#

The failure signature. DNSSEC validation is fail-closed: a validating resolver that cannot build a trusted chain does not fall back to unsigned answers, it returns SERVFAIL for everything it validates. A resolver that missed the new key does not break at the stroke of the roll. It breaks after its cached copy of the root key set expires, and that TTL is 48 hours.

48 hours is not a ceiling, it is the TTL. Failure surfaces at an unpredictable point inside that window, and on a lightly used resolver it can be later still: ICANN's 2018 review, section 3.1, "On a resolver with a single user, the time before the first query could be hours, or even days, after the root key set's TTL has expired." Resolvers that clamp TTLs downward see it sooner. So the signature is creeping SERVFAIL across all validated lookups, starting somewhere inside the 48 hours after 2026-10-11 and trailing past it, resolver by resolver, cache by cache. From the user's chair that reads as "the internet is half broken and getting worse".

Two tests tell you where you stand, and both work before the roll.

Test 1 in full: the sentinel test (RFC 8509)#

RFC 8509 defines a clever trick: a validating resolver that implements it special-cases queries for names starting root-key-sentinel-is-ta-<keytag> and root-key-sentinel-not-ta-<keytag>. It answers is-ta only if that key tag is in its root trust store, and not-ta only if it is not. The records are ordinary signed A records; the resolver's willingness to serve them is the measurement.

The catch has always been that you need a signed zone publishing those names to ask against. So we published one: the four sentinel names live under probe.isitdns.net, a real DNSSEC-signed delegation we run. Each name also carries a TXT record that says what an answer means on a sentinel-aware resolver. On a resolver without RFC 8509 support every name answers, TXT included, so read the A results against the table first; the TXT is the label, not the verdict.

Ask your own resolver for all four. Replace @1.1.1.1 with the address of the resolver you actually use (check /etc/resolv.conf, or your router's DHCP settings); the whole point is to test your path:

dig @1.1.1.1 root-key-sentinel-is-ta-38696.probe.isitdns.net A
dig @1.1.1.1 root-key-sentinel-not-ta-38696.probe.isitdns.net A
dig @1.1.1.1 root-key-sentinel-is-ta-20326.probe.isitdns.net A
dig @1.1.1.1 root-key-sentinel-not-ta-20326.probe.isitdns.net A

Read the result off this table. "Answers" means NOERROR with an A record; "refuses" means SERVFAIL:

Row two has a false positive, and it is the important caveat on this whole page. RFC 8509 section 2.2 defines what the sentinel counts: "An active root zone KSK is one that could currently be used for validation (that is, a key that is not in either the AddPend or Revoked state, as described in RFC 5011)." A resolver whose root anchor was bootstrapped inside the last 30 days has 38696 sitting in AddPend, still serving out its RFC 5011 hold-down. It produces row two exactly, and it will be Valid well before roll day. That is not hypothetical: the Unbound behaviour ICANN cited as a reason to postpone the 2017 roll was this state. Before you act on row two, read the anchor state directly (unbound-anchor file, rndc managed-keys status, and the operators section below) and check whether 38696 says AddPend or Valid.

The 20326 pair is the bonus reading: a sentinel-aware resolver answering is-ta-20326 still trusts KSK-2017, which is expected right up until the revocation phase in Q1 2027. After that the test stops meaning anything, because the revoked key carries a different tag; 20326 will simply not be present to trust.

One vantage warning: some networks (hotel wifi, plenty of home gateways) intercept port 53 and answer in place of your real resolver. If the results look strange, repeat the queries over DoH (dig +https @1.1.1.1 ...) and compare.

Live example. Captured 2026-08-18 against Cloudflare, over DoH so no middlebox could touch it:

1. Who we asked: 1.1.1.1 via dig +https, all four sentinel names, type A.
2. What came back: NOERROR with the A record for all four. Here is the first one; the other three are identical apart from the name:

dig +https @1.1.1.1 root-key-sentinel-is-ta-38696.probe.isitdns.net A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55926
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
root-key-sentinel-is-ta-38696.probe.isitdns.net. 5 IN A 192.0.2.53

1. Verdict: answering all four is row three of the table: 1.1.1.1 validates (note the ad flag) but does not implement RFC 8509 sentinel special-casing, so the sentinel cannot classify it. That is a real measurement about a major public resolver, and it is why test 2 exists.

The self-describing TXT works too, with the same caveat: 1.1.1.1 returns it because it answers everything, not because it trusts the key:

dig +https @1.1.1.1 +short TXT root-key-sentinel-is-ta-38696.probe.isitdns.net

"answer received = your resolver trusts KSK-2024 (38696). ready for the 2026-10-11 roll."

Test 2 in full: the basic validation check#

The sentinel only means something on a resolver that validates in the first place. dnssec-failed.org is a deliberately broken zone: a validating resolver must refuse it, a non-validating resolver happily serves it.

dig @1.1.1.1 dnssec-failed.org A +dnssec

• SERVFAIL: your resolver validates. The October roll applies to you; make sure test 1 or the operators section below says ready.
• NOERROR with an A record: your resolver does not validate. The roll cannot break it, and it also never protected you; dnssec covers what you are giving up.

Live example. Same vantage as above, captured 2026-08-18: 1.1.1.1 over DoH returns SERVFAIL with EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.). Validating, as expected.

What operators should verify#

If you run a resolver, "my software auto-updates the trust anchor" is the thing to verify, not assume. RFC 5011 is the automated-update mechanism: a resolver that was running and validating through the hold-down window (earliest expiry 2025-02-10) picked up 38696 on its own. The resolvers that broke in 2018 were overwhelmingly the other kind: images restored from old snapshots, containers built from stale bases, appliances nobody restarts, and configs with a hard-coded trust anchor file no process ever rewrites.

The hold-down is 30 days, and it runs per resolver. That is the trap in a container fleet. A container rebuilt from a stale base in early October bootstraps its anchor from scratch, drops 38696 into AddPend, and does not promote it to Valid until 30 days later, which is after roll day. The instance that has been running since 2025 is fine; the one that restarted last week is not, and they run the same image tag.

Reading the BIND output. rndc managed-keys status prints a state per key. A key listed as trust pending is in AddPend: seen, being held down, not yet usable for validation. Only trusted counts on roll day. One more trap: managed keys are per view. A multi-view resolver can be ready in one view and stale in another, so run the check in every view, not just the default.

Then, whatever the software:

1. Run the sentinel test (test 1) from inside your network, against your own resolver, and get row one of the table.
2. Confirm your trust anchor state matches root-anchors.xml, the normative source.
3. Put a canary on the calendar: re-run both tests in the week before 2026-10-11, and watch your SERVFAIL rate through the 48-hour window after it.

Step 2 is one command, and the file is short enough to read whole. Captured 2026-08-18, trimmed to the lines that matter:

curl -s https://data.iana.org/root-anchors/root-anchors.xml

<KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00"
           validUntil="2019-01-11T00:00:00+00:00">
    <KeyTag>19036</KeyTag>
    ...
<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>
    ...

Whatever your resolver's trust store holds must include 38696 before 2026-10-11. The retired 19036 entry at the top, complete with its validUntil, is what a finished rollover looks like in this file; 20326 gets one of those once the Q1 2027 revocation phase is done.

Your resolver has also been telling the root which keys it trusts all along: RFC 8145 trust anchor signaling is how the root operators measure fleet readiness, and it is the data the go/no-go decision leans on. It measures resolvers in aggregate though, not your resolver; the sentinel test is the per-resolver answer.

There is no fix-it-from-your-side option if you run zones rather than resolvers: authoritative-only servers do not hold root trust anchors and the roll does not touch them. The exposure sits on the validating resolver side, but it does not stay there. A non-validating stub or a forwarder pointed at a broken upstream inherits the SERVFAIL with nothing wrong on its own box, and ICANN calls out both cases plus resolvers whose anchor is fixed at build time, which is the container image and the bundled DoH stub. If your users are broken and your own resolver checks out, test the next hop up.

Already broken: stop the bleeding#

If it is October 2026, every validated lookup is SERVFAIL, and the sentinel test says the trust anchor is the cause, do these in order. ICANN's 2018 rollover review, section 3.4, gives the first two.

1. Stop the outage before you fix the cause. Either turn validation off temporarily (BIND dnssec-validation no;, Unbound: remove the auto-trust-anchor-file / trust-anchor-file line), or set a negative trust anchor for the root (RFC 7646) so the resolver answers unvalidated instead of refusing. Both trade DNSSEC protection for service. It is a bridge, not a fix, so put a timer on it.
2. Install KSK-2024 (38696). Take it from root-anchors.xml, the normative source. On Unbound, unbound-anchor -a /var/lib/unbound/root.key rewrites the anchor file.
3. On BIND, reset the managed-keys database. Editing the config does not rewrite it; the command block below does. Details under the block.
4. Re-enable validation and confirm. Run the sentinel test again and expect row one, then check rndc secroots or the Unbound anchor file for 38696 in the trusted state.

Step 3, on the resolver you are repairing:

rndc managed-keys destroy
rndc reconfig

Managed keys live in their own database, separate from named.conf, so a stale anchor survives every config reload until that database is destroyed. destroy throws it away and reconfig makes BIND bootstrap a fresh one from the configured anchor. If rndc cannot reach the server, do the same thing from the filesystem: stop named, delete managed-keys.bind (or <view>.mkeys, one file per view) from the directory named by managed-keys-directory, and start it again.

A rebuilt anchor starts its 30-day hold-down from zero. If you bootstrap after the roll has already happened, the key you installed by hand is the current signer and validation works immediately; the hold-down only governs automatic promotion of a newly seen key, not an anchor you configured.

What happened in 2018#

The only precedent we have, and it is instructive. Everything below comes from ICANN's 2018 DNSSEC KSK rollover review (PDF).

• The postponement. ICANN postponed the roll on 2017-09-27 by "at least three months", not by a year. The year fell out of the design rule that rolls happen on the 11th of January, April, July or October. The trigger was RFC 8145 signaling: 577 of 11,692 unique signaling addresses, about 5% of the resolvers that signaled, reported only the old key. That is not 5% of the Internet's resolvers. ICANN names three confounders in the same breath: dynamic addresses inflating the unique-address count, forwarders hiding the resolver behind them, and a BIND bug that made non-validating resolvers report trust anchors.
• How many users were affected: unknown, and unknowable from that data. The review, p.9: "there was no reliable way to determine how many users were using each resolver, so it was impossible to even guess the impact on users." The 0.5% figure that circulates was the rollback trigger threshold, a decision rule set in advance, not a measurement of anything.
• The 9,000 number is a telemetry artifact, not 9,000 bricked resolvers. The review, p.16, says over 9,000 resolvers are reporting KSK-2010 as their only trust anchor. Two pages later it discounts that: those reporters "clearly have no users", and some implementations report "all records from the DNSKEY records in the root zone, not just from trust anchors". Read it as a count of noisy signalers, not of broken service.
• The 2019 revocation did not produce a failure wave. This is the opposite of what most write-ups say. Review p.18: "Having two 2048-bit KSKs caused no noticeable harm ... The KSK rollover generated no evidence to support that concern." And p.16: "There were no public reports of any Internet users affected by the revocation." What actually happened on 2019-01-11 was a jump in the query rate for the root DNSKEY RRset, a cause the review records as "not yet understood".
• So why is Q1 2027 still a watch window? Because the query-rate jump was real and unexplained, and because revocation is the step that permanently retires 20326 in every RFC 5011 tracker. Worth watching. Not worth predicting an outage over.

How isitdns will cover the roll#

This site is a live resolver health monitor: the status board samples 17 public resolvers every 3 minutes, from one vantage, over DoT, asking each of them for a single pinned canary name. The same box also runs a DoH-first transport ladder over four rotating canary names every minute, as the prime vantage. That round never writes the board's numbers, and it cannot cancel a strike either: since 4 September 2026 the strike veto refuses a second opinion that shares the first one's uplink, and prime leaves through the same uplink as the board seat. What it does is fill the cross-vantage matrix and keep the heartbeat honest (functions/_prober.ts, functions/_db.ts). A resolver has to fail twice in a row before the board calls it an incident rather than a flap. So if a major resolver misses the roll, the board shows it as it happens, in the same 48-hour creep the failure signature predicts, and one bad round on its own will not move it.

The DNSSEC chain visualizer walks the live chain from the root and draws every key it finds. Today it shows both root KSKs, 20326 signing and 38696 waiting. On 2026-10-11 it will show the handover, live, from your own browser's vantage. The sentinel target stays up through the roll and through the Q1 2027 revocation and removal, so both watch windows can be measured, not guessed at.

See also#

• ksk-roll-2026: the short page, two tests and the live board
• dnssec: how the trust chain works, and why one root key anchors everything
• dnssec-troubleshooting: the field guide when the answer is already SERVFAIL
• dnssec-viz: manual for the live chain visualizer
• tldr-dnssec: the one-verdict version of the chain walk
• IANA DNSSEC files: the authoritative source for root key state, and the rollover timeline table