A resolver without the new DNS root key breaks sites on Oct 11

On October 11 the DNS root switches the key that signs its own list of public keys, only the second time that has happened, according to Cloudflare’s post on the rollover. The new key-signing key is KSK-2024, key tag 38696. It takes over from KSK-2017 as the signer of the root’s DNSKEY record set, and a resolver that checks DNSSEC signatures without trusting KSK-2024 fails DNSSEC validation from the root down.

DNSSEC validation has to start somewhere, and the root has no parent zone to vouch for its keys, so each validating resolver begins from a root key it already holds, called a trust anchor. When that anchor is not the key signing the root’s current DNSKEY set, the chain breaks at its first link, and Cloudflare’s post puts the consequence plainly: users of that resolver may be unable to reach websites under any top-level domain. Cloudflare’s write-up of the .de outage shows what a failed DNSSEC check looks like from the outside, with sites running normally and still unreachable.

Discovery has not been the hard part of this rollover. KSK-2024 has been published in the root’s DNSKEY set since January 11, 2025. RFC 5011 lets a resolver learn a new anchor on its own, after verifying the new key in signed records for at least 30 days.

The gap is retention, not discovery. Preparing for the 2018 rollover, Cloudflare saw resolvers lose anchors they had already learned when their software was upgraded or moved between machines, which is why it put KSK-2024 into its resolver’s built-in anchors in July 2024 instead of trusting the learned state. Cloudflare’s post does not rank who is at risk now, but given that 2018 account the likelier risk is resolvers rebuilt, reinstalled or migrated since the key was published, rather than ones nobody has touched.

Asking the resolver

The readiness check is two DNS queries, defined by RFC 8509 and implemented in 1.1.1.1 ahead of the switch. One name asks whether a given root key is trusted, the other asks whether it is not, and both have valid DNSSEC-signed address records, so a resolver that supports the sentinel either answers normally or replaces the answer with SERVFAIL. Cloudflare runs the labels under dnstest.dev:

dig @<resolver-ip> root-key-sentinel-is-ta-38696.dnstest.dev A +noall +comments +answer
dig @<resolver-ip> root-key-sentinel-not-ta-38696.dnstest.dev A +noall +comments +answer

A resolver that trusts KSK-2024 answers the is-ta query and returns SERVFAIL for not-ta. One that does not trust the key inverts both, answering not-ta and failing is-ta. A resolver that answers both normally is not validating or does not support the sentinel, and Cloudflare’s post is clear that this result is inconclusive rather than a pass. The browser version of the same check is at Cloudflare’s readiness test, which adds controls for an ordinary signed name and a deliberately invalid one so a passing result means something.

Cloudflare’s post notes that the browser test reaches whatever resolver the browser uses, including a VPN or Secure DNS service, and stops there. For most readers the thing worth checking is not the public site, it is the networks they check the site from. An office resolver, a VPN, or a monitoring host that loses its anchor will report the site as unreachable while server logs show nothing at all, the same class of mismatch as Search Console reporting resource failures that logs say loaded.

What to do

• If your domains use Cloudflare DNS, or your devices resolve through 1.1.1.1 or Gateway DNS, Cloudflare’s filtering resolver for businesses, there is nothing to do. Those systems already trust KSK-2024.
• If you or your hosting runs a validating resolver, point the two sentinel queries at that resolver’s own IP before October 11. If the key is missing, follow your software vendor’s instructions for updating trust anchors.
• Everything else stays as it is. This is a resolver-side change, and Cloudflare’s post is explicit that most website operators need to make no changes for it.