DNS root KSK rollover on 11 October 2026: what to check on your resolvers

On 11 October 2026 the DNS root will change its key-signing key (KSK) — the trust anchor underpinning DNSSEC — for only the second time in its history. For anyone running their own DNSSEC-validating resolver, rather than relying on Cloudflare, Google or another public operator, now is the time to check the configuration, because a missing trust anchor means DNS resolution breaks for every domain.

What changes technically

The KSK signs the root's set of public keys (the DNSKEY set), including the DS records of top-level domains such as .com. From 11 October, signing duties pass from the old key to the new one.

Element	Outgoing key	Incoming key
Name	KSK-2017	KSK-2024
Key Tag	20326	38696
Published in the root zone	since 2018	since 11 January 2025
Becomes active signer	until 10 October 2026	from 11 October 2026
Algorithm	RSA/SHA-256	RSA/SHA-256 (unchanged)

This is a planned key replacement, not an algorithm change: both keys use 2048-bit RSA/SHA-256. KSK-2024 was published in the root zone on 11 January 2025, and on 11 October 2026 it will replace KSK-2017 as the key signing the root's DNSKEY record set.

Who needs to act

Operators of DNSSEC-validating resolvers must verify that KSK-2024 (key tag 38696) is present in their trust anchor configuration, rather than assuming automatic updates have succeeded; if the key is missing, automatic update settings should be confirmed and the vendor's instructions followed. According to ICANN guidance, if a DNSSEC-validating resolver does not have KSK-2024 configured by this date, the network will experience total DNS resolution failures, cutting users off from internet access.

The RFC 5011 mechanism should already have updated most resolvers automatically: data shows the current adoption curve closely tracks that of the 2018 rollover, with over 95 per cent of monitored resolvers having recognised and adopted KSK-2024. That said, a portion of installations remain stuck, often due to outdated software or machine migrations that caused the automatically-learned trust anchor state to be lost.

To quickly check your own configuration, you can query a resolver with an RFC 8509 sentinel query:

dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev A +short

A valid response indicates that the queried resolver already trusts KSK-2024; a SERVFAIL means the key has not yet been accepted. An equivalent browser-based test is available at dnstest.dev/ksk-2024.

After 11 October

The change of signer does not close the process: the upgrade to new Hardware Security Modules made it necessary to generate the KSK-2024 key, after the pandemic had already forced remote participation in signing ceremonies. ICANN plans to revoke KSK-2017 and remove it from the root zone during 2027, thereby separating the end of signing from the definitive removal of the old key.