DNS root key is set to change October 11; resolvers must trust it first

Every DNSSEC check starts from a key that nothing above it can vouch for. A resolver trusts that key because someone put it there. According to Cloudflare, the DNS root is scheduled to change that key on October 11, 2026, for only the second time. The first change showed that the steps around the cryptography can fail even when the cryptography works. This one asks the same question again: did every resolver keep the update?

What is changing

Cloudflare's engineers describe a scheduled swap of the root's key-signing key, or KSK. The incoming key is called KSK-2024 and carries key tag 38696. On the switch date it takes over from KSK-2017, tag 20326, as the key that signs the root's published list of public keys. That list is known as the DNSKEY set.

Any resolver that checks DNSSEC signatures must already hold the new key as trusted by then.

If a resolver does not, healthy websites can become unreachable. Cloudflare says the effect could reach sites under any top-level domain, for that resolver's users.

How the chain of trust works

A resolver is the service that looks up website addresses for your device. With DNSSEC, it also checks digital signatures on the answers. Each level vouches for the one below. The root vouches for .com, and .com vouches for cloudflare.com.

The root sits at the top, so no parent can confirm its keys. Each validating resolver therefore begins with a stored root key, or a fingerprint of one. That stored starting point is the trust anchor. Every other check is measured against it.

The root uses two keys. The zone-signing key signs the root's records. The key-signing key signs the list that contains the zone-signing key. Replace the key-signing key, and every resolver must accept the replacement as its new starting point.

What the 2018 rollover taught

In its write-up of the first rollover in 2018, Cloudflare reported resolvers forgetting a newly learned key. It happened after software upgrades, or after a resolver moved to another machine. The key had been published early. Some resolvers did not hold on to it.

Cloudflare did not rely on that automatic learning. It added KSK-2024 to its resolver software's built-in trust anchors in July 2024. The trust arrives with the software instead of depending on saved state.

A way to ask the resolver

Having the key in software is one thing. Proving it is another. Even with the key built in, people using 1.1.1.1 or Gateway DNS could not directly confirm what the resolver answering them trusted, Cloudflare says.

RFC 8509 defines a sentinel for this. A client sends ordinary DNS queries with specially named domains. One name asks whether the key is trusted. The other asks whether it is not. A supporting resolver answers in a way that reveals its state. When KSK-2024 is trusted, the "not trusted" query is deliberately rejected with SERVFAIL.

Cloudflare's readiness test, at dnstest.dev/ksk-2024, runs these queries. It adds control checks, such as whether a deliberately invalid DNSSEC name is rejected. If the resolver does not support the sentinel, the result is inconclusive. That does not mean the key is missing.

Why this matters beyond one date

The new key still uses RSA/SHA-256, the same method as the old one. In 2018, Cloudflare wrote that a smooth rollover could open talk of changing algorithm. That talk has not yet produced a change. The root still signs with RSA.

Cloudflare says ICANN plans to revoke KSK-2017 in 2027. That is a separate step from the October switch. ICANN has also proposed a future move to ECDSA P-256. That would not be post-quantum, and Cloudflare notes it is a separate proposal.

Cloudflare argues that a post-quantum root would need another rollover. Each rehearsal tests how trust anchors are distributed, accepted and retired. This is Cloudflare's view. The point for leaders is that the weak spot is not the key's strength. It is whether every resolver in the chain follows the update.

What to ask your team

First, does anyone in the organisation run a validating resolver, in a data centre, a branch network or a managed service? If so, who owns it? Second, does it trust KSK-2024, key tag 38696? Ask for evidence, such as the readiness test result or a vendor statement. Third, if the key is missing, what do your software vendor and ICANN's guidance say to do?

A trust anchor is a promise stored on a machine. October 11 is a date to confirm the promise is still there.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.