The Internet's root key is changing. Is your resolver ready?

In 2018 the DNS root changed its signing key for the first time. The new key was published months in advance, and resolvers were built to pick it up on their own. Many did. Then some of them were upgraded, reinstalled or moved to new hardware, and the key they had learned was left behind on the old disk.

On 11 October 2026 the root changes its key again. KSK-2017, which has signed the root since that first rollover, hands over to KSK-2024. Most networks will not notice. A validating resolver that never learned the new key, or learned it and lost it, starts failing every DNSSEC-signed lookup within about two days of the switch.

Where trust starts

A DNSSEC-validating resolver does not take answers on faith. When it looks up www.example.com , the answer comes with a signature, and the resolver has to prove the key behind that signature belongs to example.com .

It does that by walking up the tree. The .com zone publishes a Delegation Signer (DS) record for example.com , which is a fingerprint of that domain's key. The root publishes a DS record for .com. Each parent vouches for its child.

The root has no parent. So every validating resolver ships with the root's public key already in its configuration. That copy is the trust anchor, and every signature the resolver checks traces back to it.

The root splits its signing across two keys. The zone-signing key (ZSK) signs the root's records, including the DS record for every top-level domain. It is replaced every three months, and nobody outside the root operators has to do anything. The key-signing key (KSK) signs only the root's list of public keys, the DNSKEY set. The resolver checks that list against its trust anchor, then uses the ZSK inside it to check everything else.

A new ZSK is easy to introduce because the KSK signs for it. A new KSK has nothing above it, so resolvers have to trust it before the day it starts signing.

How a resolver learns a new root key

The root publishes a new key long before it uses it. KSK-2024 was generated in 2024 and added to the root's DNSKEY set in January 2025, next to KSK-2017. The old key kept signing the set, so a resolver that trusted only KSK-2017 could still verify a set that contained KSK-2024.

RFC 5011 defines what happens next. A resolver that supports it sees the new key, waits at least 30 days while it keeps re-checking the signed DNSKEY set, and then adds the key as a trust anchor. That gave resolvers about 21 months. The other routes are a vendor release with KSK-2024 built in, or an operator adding it by hand. Cloudflare added KSK-2024 to the built-in trust anchors of the 1.1.1.1 resolver in July 2024.

The automatic route is the one that failed in 2018. A learned trust anchor lives in a state file. Rebuild the host, restore an old VM snapshot, ship a container from an older base image, or run an appliance that resets its config on reboot, and that file is gone or stale.

What happens to a resolver that missed it

The root's DNSKEY records have a 48-hour TTL. A resolver that cached them just before the switch keeps using that copy, already validated under KSK-2017, and keeps answering normally. When the cache expires it fetches a DNSKEY set signed by a key it does not trust. From then on it treats every signed answer as forged and returns SERVFAIL. A busy resolver gets there minutes after the TTL runs out. One serving a single machine can take hours or days longer.

To users it looks like an outage with no cause. Pages fail, or load without their images. Mail stops arriving. API calls to healthy services time out. Two people opening the same site can get different results because they sit behind different resolvers, and a machine configured with one good and one bad resolver sees slow lookups that work on retry.

A resolver that does not validate DNSSEC is unaffected. It never checked the signatures.

Check your resolver with two queries

In 2018 there was no clean way to ask a resolver which root keys it trusted. RFC 8509 adds one using ordinary DNS queries. You look up two labels under any DNSSEC-signed domain: root-key-sentinel-is-ta-38696 asks whether the resolver trusts key 38696, and root-key-sentinel-not-ta-38696 asks the opposite. A resolver that supports the sentinel answers one of them with SERVFAIL on purpose.

Cloudflare runs signed test names under dnstest.dev . Point the queries at the resolver you want to test:

RESOLVER=10.0.0.53   # your resolver's IP

dig @$RESOLVER root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
dig @$RESOLVER root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer

Against 1.1.1.1, the first query returns A records and the second returns SERVFAIL:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44476
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.6.197
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.7.197

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

If both queries come back with normal answers, the resolver either does not validate or does not support RFC 8509, and the test tells you nothing. Cloudflare's readiness test runs the same check against whatever resolver your browser uses, including one swapped in by a VPN or Secure DNS setting.

Without sentinel support, check the trust anchor store for key ID 38696 directly. On BIND:

rndc managed-keys status

On Unbound, check the file named by auto-trust-anchor-file in unbound.conf. The path varies by distribution:

grep 38696 /var/lib/unbound/root.key

For appliances and other resolvers, the vendor's documentation is the reference.

Who needs to act, and how to fix it

The rollover changes what resolvers trust, not how zones are published. Authoritative DNS keeps working either way.

Before the switch, add KSK-2024 using your vendor's procedure or upgrade to a release that ships it, then run the sentinel test again. If users are already seeing SERVFAIL after the switch, ICANN's guidance has two steps:

1. Turn DNSSEC validation off for the moment, or set a negative trust anchor for the root as described in RFC 7646 . Resolution recovers almost immediately.
2. Install KSK-2024 as a trust anchor and turn validation back on.

Then find out how the key went missing. A resolver that lost its learned trust anchor once will lose the next one the same way.

What comes after October

KSK-2017 stays in the root zone until ICANN revokes and removes it, planned for the first quarter of 2027. Its private key is then destroyed at both key management facilities through the rest of 2027.

The next rollover, expected to finish around 2029, also changes the algorithm from RSA to ECDSA. Resolvers will need the new trust anchor and software that can verify the new signatures. A post-quantum root key will need one more rollover after that. Each one depends on resolvers keeping the trust anchors they learn.

Sources

• The keys to the Internet change on October 11. Are you ready? , Cloudflare Blog
• Root Zone KSK Rollover , ICANN
• What to Expect During the Root KSK Rollover , ICANN, 27 July 2026
• Root Zone KSK Rollover FAQ , ICANN, 22 May 2026
• RFC 5011 , RFC 7646 , RFC 8509