On October 11, 2026, the DNS root is scheduled to change its key-signing key (KSK) for only the second time ever. This key anchors DNSSEC’s chain of trust, which lets DNS resolvers authenticate answers using cryptographic signatures. The change is called a KSK rollover.
Validating resolvers need to trust the new key before the switch, as otherwise healthy websites could become unreachable. When we wrote about the first root KSK rollover in 2018 , we had seen resolvers lose their learned trust in the new key during software upgrades or moves between machines. Publishing the key well in advance was only part of the job.
We also needed to know whether resolvers had retained it, and we couldn’t give users a practical way to check. Most website operators do not need to make any changes for this rollover. If you run a DNSSEC-validating resolver, check that it trusts the new root key, KSK-2024, and follow your software vendor’s instructions to update its trust anchors if the key is missing.
If you use Cloudflare for your domain's DNS or rely on 1. 1. 1.
1 and Gateway DNS, you do not need to take any action — our systems already trust KSK-2024. To check ahead of time, visit our rollover readiness test . It asks the resolver your browser uses whether it trusts the new key.
The test uses RFC 8509: A Root Key Trust Anchor Sentinel for DNSSEC , which we’ve implemented in 1. 1. 1.
1 ahead of the rollover. Where DNSSEC trust begins A DNS resolver looks up the addresses of websites and other services for your device. DNSSEC lets it check digital signatures on DNS records to verify that they are authentic and have not been changed.
The resolver also needs to check that the public keys used to verify those signatures belong to the right domains. For cloudflare. com , this follows a chain of trust from the DNS root to .
com , then to cloudflare. com . Each parent publishes a Delegation Signer (DS) record containing a fingerprint of its child’s public key.
For example, . com publishes the DS record for cloudflare. com , allowing the resolver to check that domain’s key.
That chain needs a starting point. The root, however, has no parent to confirm which keys belong to it. Instead, a resolver checking DNSSEC starts with a root public key, or its fingerprint, that it already trusts.
This is called a trust anchor. The root’s signing keys have two different jobs. The zone-signing key (ZSK) signs the root’s DNS records, including the DS records for top-level domains such as .
com . The key-signing key (KSK) signs the list of public keys published by the root, called the DNSKEY record set. The resolver uses its trusted KSK to verify that list, then uses the ZSK from the list to verify the root’s other records.
The diagram below shows the arrangement for a typical signed zone. For the root, trust comes from the resolver’s trust anchor rather than a DS record in a parent zone. Our posts about the .
de and the . al rollover failures showed the consequence of failed DNSSEC checks: websites can be working normally but still be unreachable. The root KSK rollover changes the starting point of those checks.
If a resolver does not trust the replacement key, its users may be unable to reach websites under any top-level domain. The new key is KSK-2024 , identified by key tag 38696 . It will replace KSK-2017, key tag 20326 , as the signer of the root’s DNSKEY set.
Validating resolvers need to trust the new key before that switch. How resolvers get the new root key RFC 5011 lets resolvers learn a new root trust anchor automatically. The root publishes the new KSK alongside the existing one in its DNSKEY set.
The existing KSK continues signing that set, so a resolver can use the key it already trusts to verify the records containing the replacement. Before accepting the new key as a trust anchor, the resolver waits at least 30 days and keeps checking the root’s signed DNSKEY records. The new key must remain in the records it checks during that period.
After the wait, the resolver must successfully verify the records containing the new key again before accepting it. For this rollover, KSK-2024 has been published in the root’s DNSKEY set since January 11, 2025 . That gave resolvers with automatic trust-anchor updates time to discover and accept it ahead of the scheduled October 11, 2026 signing change.
Each resolver’s waiting period starts when it first sees and verifies the new key. For our resolver, we added KSK-2024 directly to the software’s built-in trust anchors in July 2024, alongside KSK-2017. A resolver running the updated software therefore has the new anchor available from startup.
We chose this approach because of our experience during preparations for the first rollover. As described in our 2018 post , software upgrades and moves between machines caused some resolvers to lose their learned trust-anchor state. We fixed that by updating the software to include the new anchor by default.
Including KSK-2024 in the software likewise avoids depending on each resolver retaining a key it learned automatically. Even though we added KSK-2024 to our resolver’s built-in trust anchors in July 2024, users of 1. 1.
- 1 and Gateway DNS had no direct way to check whether the resolver answering their queries trusted the new key. This time, ask the resolver RFC 8509 defines the root key trust anchor sentinel, a way to ask a supporting resolver whether it trusts a particular root key.
It uses ordinary DNS queries with specially named domains. Our readiness test website uses this protocol to check for KSK-2024. Two names ask opposite questions: is-ta-38696 asks whether the key is trusted, not-ta-38696 asks whether it is not trusted.
Both names have valid DNSSEC-signed address records. A resolver that supports the sentinel first validates those records, then either returns the response directly or replaces the answer with SERVFAIL , depending on whether it trusts the key.
Originally published at blog.cloudflare.com
