DNSSEC Root Key Changes on October 11: Who Needs to Check Their Resolver?

On October 11, 2026, the DNS root zone will be signed with a new DNSSEC key, called KSK-2024. Administrators running their own DNS resolver with DNSSEC validation enabled must verify that it knows this key, or they risk resolution failures. For internet users, domain owners, and businesses relying on their ISP's resolver or a public resolver, nothing changes.

As a reminder, DNSSEC signs DNS records so that a resolver can verify that a response has not been tampered with. This verification relies on a chain of trust whose starting point is the Key Signing Key (KSK) of the root zone.

The current KSK, called KSK-2017 (key tag 20326), has been signing the root since the very first rollover, carried out in October 2018. But it is about to give way to KSK-2024, a key identified by key tag 38696. In an article published on July 27, 2026, Roy Arends from ICANN recalls that this new key was first published in the root zone on January 11, 2025. That is about 21 months of notice, which in theory leaves plenty of time to act.

Starting October 11, 2026, the root zone will be signed exclusively with KSK-2024. The old key will then be removed in January 2027, according to ICANN's press release. That will mark the start of a shorter cycle of only three years. Indeed, the next rollover scheduled for 2029 is expected to change the signing algorithm to ECDSA.

Who is affected, and what happens if this is missed?

For most individuals and organizations, there is nothing to do. No action is required in the following cases:

• You use your ISP's resolver or a public resolver (Google, Cloudflare, Quad9, etc.): it is up to the resolver operator to make sure it knows the new key.
• You own a domain name signed with DNSSEC: the root KSK signs only the root zone's key set. Your zone keys do not change.
• Your resolver does not validate DNSSEC: according to ICANN, it will see no difference.
• Your DNS server forwards its queries to a forwarder without validating them itself: the forwarder is the affected component, not your server.

Those affected are the ones running their own recursive resolver with DNSSEC validation enabled: ISPs, hosting providers, businesses, or anyone running a recursive DNS resolver in their home lab. And among them, only those whose trust anchor does not yet contain KSK-2024. According to ICANN, more than 95% of resolvers reporting this information already recognize it, largely thanks to automatic trust anchor updates (RFC 5011). The risk mainly concerns configurations where this update does not apply: manually configured anchor, outdated software...

In terms of consequences, a resolver that only trusts KSK-2017 will no longer be able to validate responses. ICANN then warns of a complete DNS resolution failure for users of that DNS resolver, because it will no longer be able to verify record signatures. The outage will not necessarily be immediate, because keys are cached for 48 hours (TTL). After that, the impact will be significant because DNS resolution affects web browsing, sending and receiving e-mail, and more...

"Many applications - including containerized services and software using the DNS-over-HTTPS protocol or other private minimal resolver configurations - use resolvers configured at compile time or deployment time, regardless of the host operating system's resolver settings. In these specific cases, the resolver in use may not result from an explicit operational choice; troubleshooting will then require determining which resolver is configured in the application.", warns ICANN in its guide.

How do you check your resolver?

ICANN stresses one point: do not assume that automatic trust anchor updates (RFC 5011) have worked. If you use your own DNS resolver and DNSSEC validation is enabled, check for key tag 38696 in the configuration.

• ISC BIND: with the dnssec-validation auto option, BIND uses the built-in root key (also referenced in the bind.keys file) and keeps it updated automatically according to RFC 5011. Since BIND 9.11, the rndc managed-keys status command can be used to verify that key tag 38696 is known and trusted. On the other hand, a key hard-coded in the configuration (for example: static-key in a trust-anchors block) may never be updated automatically. BIND is the DNS server presented in my tutorial on installing and configuring a Bind9 DNS server on Debian.
• Unbound and PowerDNS Recursor: root.key file.
• Windows Server: the DNS server validates public names only if a trust anchor has been manually added for the root (Add-DnsServerTrustAnchor -Root). On your server, if the Get-DnsServerTrustPoint command does not list the root ("."), your server is not affected. Otherwise, Get-DnsServerTrustAnchor -Name . must show key tag 38696. Trust anchors for signed Active Directory zones are not affected.

And if the issue is discovered after October 11? ICANN offers a fallback solution: temporarily disable DNSSEC validation, or configure a negative trust anchor for the root (RFC 7646). Then KSK-2024 must be installed as soon as possible, and validation re-enabled. So this is a patchwork fix, not a real solution.

Find all the resources on the page dedicated to the KSK rollover on ICANN's website.

Florian Burnel Co-founder of IT-Connect

Systems and network engineer, co-founder of IT-Connect and Microsoft MVP "Cloud and Datacenter Management". I'd like to share my experience and discoveries through my articles. I'm a generalist with a particular interest in Microsoft solutions and scripting. Enjoy your reading.

See Full Bio