Internet Root Keys Set to Change on October 11
The domain name system root is preparing for only its second-ever key-signing key rollover, changing the cryptographic anchor that secures internet traffic validation.
Radwan AbdulhadiEditor and technology writer
Upcoming DNS Root Key Rollover
On October 11, the DNS root is scheduled to change its key-signing key for only the second time in history. This critical change, known as a KSK rollover, updates the cryptographic anchor of DNSSEC's chain of trust, which allows DNS resolvers to authenticate answers using cryptographic signatures. Validating resolvers must trust the new key before the switch occurs, or else healthy websites could suddenly become unreachable for users.
The new replacement key is designated as KSK-2024 and carries key tag 38696. It will take over from the older KSK-2017 key, which utilizes key tag 20326, as the primary signer of the root's DNSKEY record set. Similar past rollover complications, such as those documented in analyses of the .de and .al rollover failures, demonstrate the severe consequences of failed DNSSEC checks where operational websites become inaccessible due to untrusted keys.
Understanding the Chain of Trust
A DNS resolver looks up the addresses of websites and other network services for user devices. DNSSEC empowers these resolvers to check digital signatures on DNS records, verifying that the records are authentic and have not been altered in transit. The resolver also needs to ensure that the public keys used to verify those signatures belong to the correct domains.
For domains like cloudflare.com, this process follows a strict chain of trust originating at the DNS root, moving down to .com, and finally reaching the destination domain. Each parent zone publishes a Delegation Signer record containing a fingerprint of its child's public key. Because the root zone has no parent to confirm its keys, resolvers must rely on a pre-configured root public key, or trust anchor, to start the validation process.
Automatic Discovery and Trust Anchors
The root's signing keys serve two distinct functions. The zone-signing key signs regular root records, while the key-signing key signs the list of public keys published by the root. Under normal protocol operations governed by RFC 5011, resolvers can learn new root trust anchors automatically by observing the root's published DNSKEY sets over a designated waiting period.
For this particular event, KSK-2024 has been actively published in the root's DNSKEY set since January 11, 2025. This extended timeline was designed to give resolvers utilizing automatic trust-anchor updates enough time to discover and accept the new key ahead of the scheduled signing change.
Testing Resolver Readiness
To help network operators and users verify whether their infrastructure is prepared for the upcoming transition, specialized testing tools have been deployed across the web. Administrators can utilize the rollover readiness test to evaluate if the DNS resolver currently serving their browser correctly recognizes and trusts the upcoming key.
These diagnostic capabilities rely on the protocol outlined in RFC 8509, which establishes root key trust anchor sentinels. By using ordinary DNS queries combined with specially named domains, systems can query supporting resolvers to determine if they successfully trust the targeted key-signing key without risking disruptions to regular web browsing traffic.
Required Actions for Operators and Users
Most website operators do not need to make any explicit changes to accommodate the upcoming root key rollover. Individuals and organizations running their own DNSSEC-validating resolvers should review their software vendor guidelines to confirm that their trust anchors are fully updated if the new key is absent.
Users who rely on public infrastructure like Cloudflare's 1.1.1.1 or Gateway DNS do not need to take any action because those systems already natively trust KSK-2024. Cloudflare previously wrote about the first root KSK rollover in 2018, noting that software upgrades or machine migrations can occasionally cause resolvers to lose learned state, prompting the proactive inclusion of default anchors for future events.
Sources
- Cloudflare BlogThe keys to the Internet change on October 11. Are you ready?
Continue chronologically
Related entity coverage
Related stories
Cloudflare Announces OHTTP Gateway Closed Beta
Cloudflare announces a closed beta for its new self-serve OHTTP Gateway and renames Privacy Gateway to Cloudflare OHTTP Relay.
Cloudflare and IETF Fight Quantum IPsec Downgrade Threats
Cloudflare and the IETF have developed a new transcript authentication extension to protect post-quantum IPsec tunnels from downgrade attacks.
Cloudflare interns ship AI-assisted work across 48 teams
Cloudflare says more than 750 interns have shipped products across 48 teams, using AI to accelerate work in security, infrastructure and support.
Cloudflare Ranks Fastest Across 74% of Top Networks
Cloudflare has expanded its network performance lead, ranking as the fastest provider across 74% of the world's top 1,000 networks using background telemetry.
