The infrastructure underpinning the global internet is preparing for a rare and critical administrative transition. On October 11, 2026, the Domain Name System (DNS) root is scheduled to change its key-signing key (KSK) for only the second time in history. This pivotal cryptographic update anchors the chain of trust for DNSSEC—the security extensions that allow DNS resolvers to authenticate answers using cryptographic signatures.
Referred to as a KSK rollover, this operation requires validating resolvers worldwide to trust the new key prior to the switch. Without this preparation, healthy and legitimate websites risk becoming entirely unreachable for users whose resolvers fail to recognize the updated cryptographic anchor.
When the first root KSK rollover occurred in 2018, network operators observed that some resolvers lost their learned trust in the new key during routine software upgrades or when migrating between machines. That experience underscored that simply publishing the new key well in advance was only part of the challenge. Operators also needed a reliable way to confirm whether resolvers had successfully retained the key, a capability that was largely missing at the time.
For the vast majority of website operators, no direct action is required for this upcoming rollover. However, organizations and network administrators running DNSSEC-validating resolvers must verify that their systems trust the new root key, designated as KSK-2024, and follow their software vendor instructions to update trust anchors if the key is absent. For users who rely on Cloudflare for their domain’s DNS or utilize 1.1.1.1 and Gateway DNS, no manual intervention is necessary, as those systems already trust KSK-2024. To help administrators check readiness ahead of time, a dedicated rollover readiness test has been made available at dnstest.dev/ksk-2024, which queries the user’s browser resolver to determine if it trusts the new key using protocols established in RFC 8509.
Where DNSSEC Trust Begins
To understand the gravity of a root key rollover, it is necessary to examine how the DNS resolution process establishes authenticity. A DNS resolver acts as an intermediary, looking up the addresses of websites and other network services for a user device. Without security extensions, these lookups are vulnerable to manipulation. DNSSEC introduces digital signatures to DNS records, allowing a resolver to verify that the information is authentic and has not been altered in transit. Furthermore, the resolver must check that the public keys used to verify those signatures genuinely belong to the correct domains.
For a domain like cloudflare.com, this verification follows a continuous chain of trust originating at the DNS root, moving down to the .com top-level domain, and finally reaching cloudflare.com itself. Each parent zone publishes a Delegation Signer record containing a cryptographic fingerprint of its child’s public key. For instance, the .com registry publishes the Delegation Signer record for cloudflare.com, enabling resolvers to validate the domain’s key.
However, this entire chain requires a definitive starting point. The root zone of the DNS has no parent organization to confirm which keys belong to it. Consequently, a resolver checking DNSSEC must begin with a root public key, or its cryptographic fingerprint, that it already implicitly trusts. This foundational element is known as a trust anchor.
The root’s signing keys serve two distinct roles within the architecture. The zone-signing key is responsible for signing the root’s everyday DNS records, including the Delegation Signer records for top-level domains like .com. Meanwhile, the key-signing key signs the list of public keys published by the root, which is known as the DNSKEY record set. A resolver utilizes its trusted KSK to verify that master list, and then employs the zone-signing key from that verified list to check the root’s remaining records.
While typical signed zones derive their trust from a parent zone, the root zone relies entirely on the resolver’s pre-configured trust anchor. Past incidents involving top-level domain rollovers, such as those affecting .de and .al, vividly demonstrated the consequences of failed DNSSEC checks: websites that are otherwise operating normally can suddenly become completely unreachable to validation-strict users. The upcoming root KSK rollover shifts the foundational starting point of these entire verification checks. If a resolver fails to trust the replacement key, its users may find themselves unable to access websites across any top-level domain whatsoever.
The incoming cryptographic asset is officially designated as KSK-2024, carrying the key tag 38696. It will ultimately replace KSK-2017, which is identified by key tag 20326, as the primary signer of the root’s DNSKEY set. Validating resolvers must establish trust in this new key before the scheduled transition date.
How Resolvers Acquire the New Root Key
Standards defined in RFC 5011 allow resolvers to learn a new root trust anchor automatically through the network. Under this mechanism, the root zone publishes the new KSK right alongside the existing one within its DNSKEY set. Because the older KSK continues to sign that master set, a resolver can leverage the key it already explicitly trusts to verify the records containing the replacement.
Before a resolver accepts a new key as a legitimate trust anchor, it undergoes a mandatory waiting period of at least 30 days while continuously monitoring the root’s signed DNSKEY records. The replacement key must remain present in the records checked throughout that entire duration. Following the completion of the waiting period, the resolver must successfully verify the records containing the new key once more before officially adopting it.
For the current rollover, KSK-2024 has been actively published in the root’s DNSKEY set since January 11, 2025. This timeline provided resolvers utilizing automatic trust-anchor updates ample opportunity to discover and accept the key ahead of the October 2026 switch. Each individual resolver’s waiting period initiates the moment it first encounters and successfully verifies the new key.
In the case of Cloudflare’s public resolver infrastructure, engineers took a more direct route by embedding KSK-2024 straight into the software’s built-in trust anchors in July 2024, placing it side by side with KSK-2017. Any resolver operating on this updated software inherently possesses the new anchor available from the moment of startup.
This proactive approach was adopted directly as a result of operational lessons learned during preparations for the inaugural 2018 rollover. As documented in previous engineering analyses, routine software upgrades and hardware migrations caused numerous resolvers to inadvertently lose their learned trust-anchor state. By baking the new anchor directly into the default software configuration, operators can bypass the risk of depending on individual resolvers to retain a key they acquired automatically. Nonetheless, even with KSK-2024 embedded well in advance, end users relying on public services like 1.1.1.1 previously lacked a direct mechanism to query whether the exact resolver answering their queries actually trusted the new key.
Direct Querying Through Trust Anchor Sentinels
To address the visibility gap in resolver readiness, protocols outlined in RFC 8509 define a method known as the root key trust anchor sentinel. This standard allows administrators and automated tools to ask a supporting resolver whether it currently trusts a specific root key using ordinary DNS queries directed at specially constructed domain names.
The readiness test platforms leverage this protocol to check specifically for the adoption of KSK-2024. The mechanism utilizes complementary names that ask opposing questions: one queries whether a key is trusted, while the other asks whether it is not trusted. Both label variations feature valid DNSSEC-signed address records. A resolver that supports the sentinel standard first validates those underlying records before either returning the normal response directly or replacing the answer with a SERVFAIL status, depending entirely on whether it currently recognizes the key as trusted.
For a properly functioning validating resolver with full sentinel support, finding a trust status yields predictable outcomes. When KSK-2024 is trusted, querying the positive sentinel label returns a valid network response, whereas querying the negative sentinel label results in a deliberate SERVFAIL, as the resolver intentionally rejects the suggestion that the key is untrusted. Conversely, if the key is not trusted, the behavior reverses.
These sentinel labels can be deployed beneath any DNSSEC-signed domain, with testing environments utilizing domains such as dnstest.dev to evaluate resolver paths. Diagnostic tools allow engineers to execute direct queries against specific IP addresses to examine the exact response headers and flags returned by the resolver architecture.
Comprehensive testing protocols typically verify multiple conditions simultaneously—ensuring that ordinary signed names resolve correctly, that deliberately invalid DNSSEC configurations are properly rejected, and that the resolver responds appropriately to sentinel queries for the current root key. These controls help differentiate meaningful diagnostic results from standard lookup failures or unsupported protocol implementations. When sentinel support cannot be definitively established, the test outcome is classified as inconclusive rather than indicating an absolute absence of the new key. Browser-based tests evaluate the specific resolver utilized by the client device, which may be influenced by local network configurations, Virtual Private Networks, or Secure DNS settings, providing a snapshot of the immediate resolution path.
Continuity in Cryptography and Future Horizons
Both KSK-2017 and the incoming KSK-2024 rely on the RSA/SHA-256 cryptographic algorithm. This rollover effectively replaces the underlying key pair while maintaining the identical mathematical method for generating and verifying digital signatures.
During discussions surrounding the first root rollover in 2018, industry experts anticipated that a successful execution would pave the way for broader conversations regarding an eventual algorithm transition. Yet, nearly a decade later, the root zone continues to rely on RSA.
Despite keeping the same algorithm, replacing the signing key remains an essential operational exercise. It limits the lifespan of any single private key and rigorously tests the complex logistics of distributing new trust anchors, updating global resolver software, and safely retiring legacy keys. As demonstrated during the initial rollover, these administrative steps can encounter friction even when the underlying cryptography functions perfectly.
The Internet Assigned Numbers Authority has previously outlined an idealized three-year rollover interval, designed to balance routine cryptographic hygiene against the inherent operational work and risk associated with altering the root key too frequently. The extended gap since 2018 has been attributed by the Internet Corporation for Assigned Names and Numbers to pandemic-related disruptions and necessary upgrades to the highly secure hardware installations that protect the private signing keys.
Shifting to an entirely different algorithm would require resolvers to possess both a new trust anchor and updated software capable of verifying unfamiliar signature types. Conducting regular key rollovers allows operators to practice and refine trust-anchor distribution mechanisms while keeping algorithmic variables constant.
The administrative timeline extends well beyond the initial October switch. The transition will continue into 2027, during which ICANN plans to formally revoke KSK-2017, remove it entirely from the root zone configuration, and securely destroy its private key. This timeline highlights an important distinction in DNS administration: stopping a key from signing zone data and removing administrative trust in that key are handled as separate, phased steps.
Looking further ahead, ICANN has also proposed a future root algorithm rollover to ECDSA P-256, an asymmetric algorithm that produces significantly smaller keys and signatures compared to traditional RSA implementations. That potential transition remains distinct from the upcoming October key replacement, and ECDSA itself is not a post-quantum cryptographic standard.
In parallel, public resolvers have begun integrating post-quantum capabilities, with infrastructure like 1.1.1.1 adding validation support for ML-DSA-44 signatures designed to withstand threats posed by future quantum computing architectures. For the entire DNSSEC chain of trust to achieve post-quantum security, individual signed domains, their respective parent zones, and the central root must all eventually transition to post-quantum cryptography. At the root level, this will necessitate the introduction of a post-quantum KSK and widespread adoption by global resolvers.
The routine rollovers performed today serve as crucial dry runs, enabling network operators to test how effectively replacement trust anchors are distributed, verify whether resolvers have successfully accepted them, and practice retiring legacy assets. While this October’s event preserves the RSA algorithm, it exercises the exact trust-anchor update pipelines that will be mandatory when the root eventually migrates to post-quantum standards. Tools like trust anchor sentinels provide the necessary visibility to monitor whether resolvers are keeping pace with these essential infrastructural updates.
Industry bodies continue to encourage DNS providers and resolver developers to implement RFC 8509 sentinel support broadly across their networks. Network administrators and users alike benefit from transparent mechanisms that verify resolver readiness well in advance of major cryptographic transitions. As the October 11 deadline approaches, operators of validating resolvers are urged to confirm that their systems recognize KSK-2024 and to consult official administrative guidance if any updates are required.
Leave a Reply