Is your resolver ready for the 2026 root key rollover?
On October 11, 2026, the DNS root is scheduled to switch from KSK-2017 (key tag 20326) to KSK-2024 (key tag 38696) to sign its DNSKEY set. A DNSSEC-validating resolver needs to trust the new public key to continue authenticating DNS answers after the switch. Without it, otherwise healthy sites may appear unreachable.
This check uses RFC 8509 trust anchor sentinels to ask the resolver used by your browser whether it trusts KSK-2024. It also checks an ordinary valid name, a deliberately invalid DNSSEC name, and the current root key. If your resolver does not support the sentinel, the test cannot tell whether it trusts KSK-2024.
If this test does not confirm readiness, use ICANN's rollover guidance to check that your resolver has KSK-2024 (key tag 38696) in its trust anchors. If it is missing, confirm automatic updates are enabled and follow your resolver vendor's update instructions; if you do not manage it, ask your DNS provider. An inconclusive result alone does not mean the key is missing.
| Zone and setup | Result |
|---|---|
valid DNSSECValidly signed A recordThis ordinary signed name should resolve through a working resolver. If it does not, the other results cannot be reliably interpreted. Expected: Reachable. A blocked control makes the test inconclusive. | waiting |
invalid DNSSECDeliberately invalid signatureThis name has a broken DNSSEC signature. A validating resolver should reject it. Without this check, ordinary answers to the sentinel queries cannot establish whether DNSSEC validation is enabled. Expected: Blocked by a DNSSEC-validating resolver. | waiting |
KSK-2017not-ta-20326: current root keyRFC 8509 asks whether key tag 20326 is not trusted. A sentinel-aware resolver that still trusts the current root key replaces the valid answer with SERVFAIL. A reachable result leaves sentinel support or trust in the current key unconfirmed. Expected: Blocked when the current key is trusted and the sentinel is supported. | waiting |
KSK-2024 is-tais-ta-38696: new root keyA sentinel-aware resolver returns the signed answer only if it currently trusts KSK-2024 as an active root trust anchor. Otherwise it returns SERVFAIL. Expected: Reachable when KSK-2024 is trusted. | waiting |
KSK-2024 not-tanot-ta-38696: new root keyThis is the opposite check: a sentinel-aware resolver returns SERVFAIL when it trusts KSK-2024 and preserves the signed answer when it does not. Both KSK-2024 names resolving may indicate unsupported sentinels or mixed resolver state. Expected: Blocked when KSK-2024 is trusted. | waiting |
How to read this test
- When the controls pass, a reachable
is-ta-38696and blockednot-ta-38696indicate that KSK-2024 is trusted. The reverse indicates it is not yet trusted. If all three sentinel names resolve, RFC 8509 support was not detected; this says nothing about the new key. For rows we can interpret, a check means the result matches a ready resolver; a cross means it does not. - A fulfilled HTTPS request counts as reachable regardless of its HTTP status. Blocked requests can also result from network or browser problems, not just DNS
SERVFAIL; timeouts are inconclusive. - The browser uses its configured resolver. Secure DNS, VPNs, forwarders, or multiple resolvers can affect the result. The copyable
digcommands instead query 1.1.1.1 explicitly. - Running the test contacts five HTTPS hosts under
dnstest.dev. Running it again may reuse DNS cache entries, so it does not guarantee a fresh resolver lookup. - This is a snapshot of the browser's resolver path, not a guarantee about every resolver in a fleet.