Security

Root KSK roll 2026: is your resolver ready?

On 11 October 2026 the root zone changes which key signs it, from KSK-2017 (key tag 20326) to KSK-2024 (key tag 38696). A validating resolver that trusts 38696 notices nothing. One that does not starts answering SERVFAIL for everything once its cached root DNSKEY RRset (48 hour TTL) expires and the set it fetches next is signed only by KSK-2024, a signature it cannot validate. The two tests below say which one you have. The timeline, the operator checks per resolver software, the fix, and the 2018 history are on ksk-roll-2026-reference.

Asks the sentinel name that says whether a resolver trusts root key 38696.

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

; <<>> DiG 9.20.11-0ubuntu0.2-Ubuntu <<>> @1.1.1.1 root-key-sentinel-is-ta-38696.probe.isitdns.net A

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status:

NOERRORThe server had no complaint about the question.

, id: 54785

;; flags:

qrThis message is the answer coming back, not the question going out.

rdYou asked this server to go and find the answer for you.

raThis server says it is willing to go and find answers for you.

adThis server says it checked the signatures, and they held up.

; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;root-key-sentinel-is-ta-38696.probe.isitdns.net. IN

AYou asked for the IPv4 address this name points at.

;; ANSWER SECTION:

root-key-sentinel-is-ta-38696.probe.isitdns.net.

5How many seconds this answer can be reused before asking again. From a cache it is the time left, so it counts down.

IN A 192.0.2.53

;;

Query timeHow long this one lookup took, start to finish.

: 157 msec

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

;; WHEN: Mon Sep 14 17:42:31 CDT 2026

;; MSG SIZE rcvd: 92

good: NOERROR here AND SERVFAIL for the not-ta-38696 twin, which is the pair RFC 8509 defines

bad: NOERROR for both names, which means the resolver does not implement the sentinel at all

run this query in the dig tool →

Test 1: does your resolver trust the new key?#

RFC 8509 sentinel: a validator that implements it answers is-ta-38696 only when 38696 is an active trust anchor in its store, and not-ta-38696 only when it is not. The names are ordinary signed A records under probe.isitdns.net, a delegation we run. Replace @1.1.1.1 with the resolver you actually use.

RFC 8509 uses three queries, not two. The third is a name whose DNSSEC signature cannot be validated: bogus.probe.isitdns.net, a signed child of the same delegation whose DS in the parent was made from a key that no longer exists. A resolver that validates fails closed on it and answers SERVFAIL. A resolver that does not validate hands you the A record.

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 bogus.probe.isitdns.net A

`is-ta`	`not-ta`	`bogus`	Verdict
answers	`SERVFAIL`	`SERVFAIL`	Ready
`SERVFAIL`	answers	`SERVFAIL`	Not ready, or the anchor is under 30 days old and 38696 is still in the RFC 5011 hold-down. Check the anchor state before acting: KSK roll 2026: root key sentinel (RFC 8509)
answers	answers	`SERVFAIL`	Validates, no sentinel support. This test says nothing about its anchors; check the anchor by hand
answers	answers	answers	It does not validate DNSSEC at all. The roll cannot break it, and it never protected you: dnssec
`SERVFAIL`	`SERVFAIL`	any	No determination from the sentinel (the board prints "no determination (both SERVFAIL)"). Most often a resolver that cannot validate the zone at all, broken already and not because of the roll: dnssec-troubleshooting
any other combination			RFC 8509 makes no determination. A resolver farm whose members disagree can produce one

If port 53 is intercepted where you sit (hotel wifi, many home gateways), repeat over DoH: dig +https @1.1.1.1 ....

Test 2: the same question, someone else's zone#

The third query above already answers this. dnssec-failed.org asks it against a zone nobody here operates.

dig @1.1.1.1 dnssec-failed.org A +dnssec

SERVFAIL: your resolver validates. The roll applies to you; test 1 must say ready.
NOERROR with an A record: it does not validate. The roll cannot break it, and it never protected you: dnssec.

The two should agree. If dnssec-failed.org says SERVFAIL and bogus.probe.isitdns.net answers, believe dnssec-failed.org: it means our own test name has stopped being broken.

The public resolvers, live#

The same test, asked of every public resolver this site monitors, from the site's edge vantage over each resolver's own transport. Five names per resolver: the sentinel pair for KSK-2024, the sentinel pair for KSK-2017, and the one bogus name. At most 20 minutes old.

loading the live sentinel board from /api/ksk

dig +short ksk.isitdns.net TXT

Three dates#

Date	Event
2025-01-11	KSK-2024 (38696) published into the root DNSKEY RRset
2026-10-11	KSK-2024 becomes the sole signer; KSK-2017 stays published, stops signing
Q1 2027	KSK-2017 revoked, then removed. A second watch window

Sources and the full timeline: KSK roll 2026: root key sentinel (RFC 8509).