On October 11, the DNS root will start using KSK-2024 to sign its published key set. It is only the second root key-signing-key rollover in the history of DNSSEC, and the quietness of the change is part of the design. Most people should notice nothing. A smaller group of resolver operators needs to make sure that silence is earned.
The root key is not a TLS certificate and it does not encrypt DNS traffic. It is the trust anchor that lets a validating resolver prove that the signatures it encounters on the way down the DNS hierarchy are connected to the real root. If a resolver still trusts only the retiring key when the new signer takes over, valid DNS answers can begin looking forged. Healthy sites then fail with SERVFAIL.
Cloudflare's rollover briefing puts the operational deadline in plain terms: validating resolvers need to trust KSK-2024, key tag 38696, before the switch. Everyone else mainly needs to understand why a key published almost two years ago can still expose forgotten infrastructure on one particular Sunday.
The risky part is not generating a replacement key. It is discovering which resolvers never learned to trust it.
The Root Is Deliberately Parentless
DNSSEC works as a chain. A signed domain publishes keys for verifying its records. Its parent publishes a Delegation Signer record that identifies the child's key. A resolver can therefore walk from a trusted parent to a child, verify the child's signatures, and keep moving down the name.
The root has no parent. A validating resolver has to begin with something already trusted: a root public key, or its fingerprint, installed as a trust anchor. From there the resolver can authenticate the root's DNSKEY set, the root can authenticate the keys used by top-level domains, and those domains can authenticate the zones below them.
trusted root KSK
-> verifies the root DNSKEY set
-> accepts the root zone-signing key
-> verifies DS records for top-level domains
-> continues the chain to the requested nameThe two root keys have different jobs. The zone-signing key, or ZSK, signs ordinary root-zone records, including the DS records that point toward top-level domains. The key-signing key, or KSK, signs the DNSKEY set containing the root's public keys. The October rollover changes which KSK signs that set. It does not change the algorithm: both KSK-2017 and KSK-2024 use RSA with SHA-256.
That distinction matters because the cryptography is the easy part to describe. The operational problem is distributing a new starting point to recursive resolvers that may be old, isolated, restored from snapshots, rebuilt from stale images, or carrying trust-anchor state that nobody remembers owning.
A Rollover Is A Long Transition
KSK-2024 has appeared in the root's DNSKEY set since January 11, 2025. That long overlap is how conforming resolvers learn the replacement without an administrator copying keys around by hand.
RFC 5011 defines the automated update process. A resolver that already trusts the current KSK sees the new key inside a DNSKEY set signed by that trusted key. It waits at least 30 days while continuing to observe the candidate, then verifies the set again before promoting the new key into its trust-anchor state.
The delay protects against a brief malicious or mistaken publication becoming permanent trust. It also means a resolver's readiness depends on its own history. A machine that was offline, reset, cloned, or upgraded incorrectly may not have retained the same anchor state as an otherwise identical peer.
Some resolver software ships the new anchor directly. Cloudflare says it added KSK-2024 to its resolver's built-in anchors in July 2024 after the first rollover exposed how software upgrades and machine moves could erase learned state. That is a useful reliability pattern: automatic learning remains valuable, but a current software package should start with current trust rather than betting everything on mutable local history.
October 11 is therefore a signing transition, not the whole lifecycle. The old key remains part of a managed retirement process that continues into 2027. Stopping use, revoking trust, removing the public key, and eventually deleting the private key are separate events. Treating rollover day as a single flip hides the safeguards on both sides of it.
The Sentinel Makes Hidden State Testable
Trust-anchor state normally lives inside the resolver, out of sight of the person using it. RFC 8509 adds a clever diagnostic: specially formed DNS names can ask a supporting resolver whether it trusts a root key with a particular key tag.
For KSK-2024, one query asks whether key tag 38696 is trusted and another asks whether it is not trusted. Both names have valid DNSSEC-signed address records. A validating resolver with sentinel support either returns the answer or deliberately substitutes SERVFAIL, depending on its local trust state.
root-key-sentinel-is-ta-38696.dnstest.dev
root-key-sentinel-not-ta-38696.dnstest.devThe deliberately failed response is the signal. When the new key is trusted, the is-ta name resolves and the not-ta name fails. When it is not trusted, the results reverse. A good readiness test also checks an ordinary signed name, a deliberately broken DNSSEC name, and a sentinel for the current key. Without those controls, a timeout or a resolver that does not implement the sentinel could be mistaken for a meaningful verdict.
Cloudflare has implemented the sentinel in 1.1.1.1 and published a browser-based check at dnstest.dev/ksk-2024. The path matters. A browser may use Secure DNS, an operating-system resolver, a corporate gateway, or a VPN-provided service. A command that explicitly queries a resolver tests that endpoint instead. Operators should check every real path they are responsible for, not just the resolver nearest their laptop.
Who Actually Needs To Act
Most domain owners do not need to rotate their own keys because of this event. Users of Cloudflare's authoritative DNS, 1.1.1.1, or Gateway DNS do not need to change anything, according to the company. Ordinary users should not install mystery certificates or follow instructions that claim the rollover requires a browser update.
The action belongs with operators of DNSSEC-validating recursive resolvers. They should inventory the resolver software and versions they actually run, confirm that KSK-2024 is present or learned, test each production egress path, and follow the vendor's trust-anchor update instructions where it is missing. Appliances, branch-office caches, VPN resolvers, lab systems, and old virtual-machine templates deserve special attention because they are easy to omit from a central fleet view.
Monitoring should be ready for the failure shape too. A resolver that lacks the new anchor may start returning SERVFAIL broadly for signed names after the switch while unsigned names continue working. Comparing results across resolver pools and checking DNSSEC validation failures can separate a trust-anchor problem from an authoritative outage.
Disabling DNSSEC validation is a poor default response. It can make names resolve again by removing the check that detected the problem, but it trades a visible configuration failure for a silent integrity downgrade. The repair is to restore the correct trust anchor and understand why that resolver missed the managed update.
The Maintenance Window Is The Product
This rollover keeps the same signing algorithm, which is precisely why it is useful practice. The Internet is exercising the machinery for distributing trust, retaining state, testing resolvers, and retiring a key without simultaneously asking every implementation to learn new mathematics.
Future changes may carry more complexity. ICANN has discussed moving the root toward ECDSA P-256, and any eventual post-quantum chain would require new algorithms as well as new trust anchors. Neither is what happens on October 11. This event is the rehearsal that tells us whether the less dramatic distribution system works before the cryptographic transition gets harder.
The root key feels abstract because the system is designed to hide it from daily use. Rollover week makes the dependency visible. DNSSEC's chain of trust is only as reliable as the fleet of resolvers that remembers where the chain begins. KSK-2024 has been waiting in public for nearly two years. The remaining job is to prove that the edges noticed.
// Discussion
Comments
No comments yet. Start the thread.