SNACK: 3-line summary
- The DNS root’s key-signing key is scheduled to change on October 11, 2026.
- An unprepared DNSSEC-validating resolver may leave its users unable to reach otherwise healthy websites.
- Resolver operators should check their trusted keys; Cloudflare says domains using its DNS and users of 1.1.1.1 or Gateway DNS need no action.
The DNS root’s key-signing key is scheduled to change on October 11, 2026. Operators of resolvers that validate DNSSEC signatures need to check that they trust the replacement, while most website operators do not need to make changes.
Snackgirls react
Kirari: A perfectly healthy website could still fail to load? I’m curious about that invisible trust check before the page even appears.
Nea: I’d like to compare the result with and without a VPN. I wonder whether my browser would be checking the same resolver path in both cases.
Why a working website could become unreachable
DNS resolvers look up website addresses, and DNSSEC lets them authenticate answers using digital signatures. On October 11, KSK-2024 (key tag 38696) is scheduled to replace KSK-2017 (key tag 20326) as the signer of the DNS root’s public-key list, known as the DNSKEY set.
If a validating resolver does not trust the replacement, its signature checks can fail even when the website is operating normally. That resolver’s users may then be unable to reach the site, so operators need to confirm trust in the new key before the switch.
Who can leave their DNS settings alone
Cloudflare says domains using its DNS, and people using 1.1.1.1 or Gateway DNS, need no action because those systems already trust KSK-2024. Ordinary users do not need to edit root keys manually or disable DNSSEC.
An optional browser check is available through Cloudflare’s official readiness test at https://dnstest.dev/ksk-2024/ . It checks the resolver path your browser uses, which Secure DNS or a VPN can affect. The result does not cover every device or every resolver on a company network.
An inconclusive result does not mean the key is missing
A meaningful result requires support for the RFC 8509 trust anchor sentinel, a protocol that asks a validating resolver whether it trusts a particular root key. If that support cannot be established, the result is inconclusive—not proof that KSK-2024 is missing or that an outage will follow.
On a sentinel-capable, DNSSEC-validating resolver that trusts KSK-2024, the is-ta-38696 query returns a valid answer while not-ta-38696 returns SERVFAIL. That SERVFAIL response is intentional in this test: the resolver rejects the query asking whether the key is not trusted.
Check the stored key, even after automatic updates
RFC 5011 lets resolvers learn a new trust anchor automatically after at least 30 days of observation and a further successful verification. KSK-2024 has been published in the root’s DNSKEY set since January 11, 2025, but software upgrades or moves between machines can cause learned trust-anchor state to be lost.
Both the old and new keys use RSA/SHA-256. October’s switch replaces the key pair without changing the signing algorithm; it is not an ECDSA or post-quantum rollout.
If you operate a validating resolver, confirm that KSK-2024 is present and trusted rather than assuming an earlier update settled it. An inconclusive browser test calls for checking the resolver’s trusted keys directly. If the key is missing, follow your software vendor’s instructions to update the trust anchors before the switch.
Sources and checked date: October 7, 2026
Comments
0No login needed. Edit or delete your comment from the same browser.
All comments 0
한국어 · English · 日本語No comments yet. Start the conversation.