The Domain Name System (DNS) root is scheduled to change its key-signing key for only the second time in its history, when KSK-2024, with key ID 38696, replaces KSK-2017, with ID 20326, on October 11, 2026. The change is particularly relevant to operators of DNS resolvers that validate DNSSEC, because failure to trust the new key could make legitimate websites inaccessible to users of those resolvers.
What changes in the chain of trust?
DNSSEC uses cryptographic signatures to verify that DNS records are authentic and have not been modified. The chain of trust begins with a public key trusted in advance by the resolver, known as a trust anchor, and then extends from the DNS root to top-level domains such as .com and from there to final domains.
The Zone Signing Key (ZSK) signs root records, while the Key Signing Key (KSK) signs the DNSKEY record set that contains the root keys. Therefore, replacing the KSK changes the starting point the resolver relies on to validate the rest of the chain, even when the signing algorithm itself remains the same.
Do website operators need to take action?
Most website operators do not need to change their domain settings. However, those who operate DNSSEC resolvers must ensure that the resolver trusts KSK-2024 and follow the software vendor’s instructions to update trust anchors if the key is missing.
Cloudflare states that users of DNS for its domains, or of the 1.1.1.1 and Gateway DNS services, do not need to take action because its systems trust the new key. KSK-2024 was added to the root zone on January 11, 2025, giving resolvers that support automatic updates according to RFC 5011 sufficient time to discover and accept it. Cloudflare also added the key to the trust anchors embedded in its resolver software in July 2024.
How to test readiness
Cloudflare provides a test at dnstest.dev/ksk-2024 that asks the resolver used by the browser whether it trusts the new key. The test relies on RFC 8509, which defines a mechanism called the Root Key Trust Anchor Sentinel for querying the status of a trust anchor.
The test uses two opposite names: is-ta-38696 to verify that the key is trusted, and not-ta-38696 to verify that it is not trusted. For a resolver that validates DNSSEC and supports the mechanism, a successful response for the first name is valid, while the response for the second name is SERVFAIL when KSK-2024 is trusted.
However, an inconclusive result does not necessarily mean that the key is absent; the resolver may not support the sentinel mechanism. The browser test also measures the path of the resolver actually used by the browser and may be affected by the Secure DNS feature or by a VPN network. Alternatively, the queries can be sent directly to 1.1.1.1 using the dig tool.
Key change is not an algorithm change
KSK-2017 and KSK-2024 use the same RSA/SHA-256 algorithm, so the October event does not represent a transition to a new algorithm. The change will continue into 2027, when ICANN plans to retire KSK-2017, remove it from the root zone, and delete its private key; these are separate stages from its cessation of signing the DNSKEY record set.
Cloudflare says that periodically rotating keys limits the length of time a single private key is used and trains operators to distribute and test trust anchors before more complex transitions. ICANN is considering a future transition to ECDSA P-256, and the transition to post-quantum cryptography would likewise require a new root key and an updated chain of trust.
Why does this news matter?
The practical risk is not that the websites themselves will fail, but that validation will fail at an unprepared DNS resolver, which may appear to the user as an inability to access multiple domains. Therefore, the RFC 8509 test provides a practical indication that the resolver has retained the new key, but it depends on the vendor’s support for this mechanism and does not replace reviewing trust-anchor settings by infrastructure operators.