On October 11, 2026, the Domain Name System (DNS) root is scheduled to undergo a momentous and rare operational shift: changing its key-signing key (KSK) for only the second time in history. This critical cryptographic key serves as the ultimate anchor for the DNSSEC chain of trust, a foundational security architecture that allows DNS resolvers to authenticate answers using cryptographic signatures. Without proper preparation, this upcoming transition—known as a KSK rollover—carries significant risks. Validating resolvers across the global internet must implicitly trust the new key before the switch takes place, or otherwise healthy, functioning websites could suddenly become entirely unreachable for millions of users.
The complexity of altering the security foundations of the global network is well documented. When the internet experienced its first-ever root KSK rollover in 2018, infrastructure monitors observed instances where resolvers lost their learned trust in the newly introduced key during routine software upgrades or when migrating between physical or virtual machines. Publishing the new key well in advance proved to be only a fraction of the challenge. Operators also needed definitive confirmation that resolvers had successfully retained the updated key state, yet administrators lacked a practical, standardized mechanism to check this status directly.
Fortunately, the vast majority of website operators will not need to make any structural changes to accommodate this upcoming rollover. However, organizations and individuals running local DNSSEC-validating resolvers face a distinct responsibility. They must verify that their software actively trusts the new root key, designated as KSK-2024, and carefully follow their respective software vendor instructions to update their trust anchors if the key is currently absent. Conversely, users who rely on Cloudflare for their domain’s DNS management, or those who route their traffic through public services like 1.1.1.1 and Gateway DNS, are entirely unaffected and need not take any manual action, as these corporate systems already trust KSK-2024 by default.
To help administrators and curious users check ahead of the deadline, technical teams have made readiness testing tools publicly available. A dedicated rollover readiness test asks the specific resolver utilized by a browser whether it trusts the new cryptographic key. This diagnostic process relies on an established internet standard known as RFC 8509, which outlines a root key trust anchor sentinel for DNSSEC—a protocol that has already been fully integrated into services like 1.1.1.1 well ahead of the scheduled October switch.
Where DNSSEC Trust Begins
To understand why a key rollover carries such high stakes, it is helpful to examine how the DNS trust model operates. A standard DNS resolver is tasked with looking up the IP addresses of websites and other internet services whenever a user’s device requests them. DNSSEC enhances this traditional process by enabling resolvers to check digital signatures attached to DNS records, thereby verifying that the data is genuinely authentic and has not been maliciously altered in transit. Additionally, the resolver must ensure that the public keys utilized to verify those signatures legitimately belong to the correct, intended domains.
For a domain like cloudflare.com, this verification follows a strict, unbroken chain of trust originating at the DNS root, descending down to the .com top-level domain, and finally terminating at the individual domain name. Each parent zone in this hierarchy publishes a Delegation Signer record containing a cryptographic fingerprint of its child’s public key. For instance, the .com zone publishes the specific DS record for cloudflare.com, enabling any compliant resolver to inspect and validate that domain’s key.
However, this entire chain requires an absolute starting point. The DNS root itself is unique because it has no parent zone above it to vouch for which keys rightfully belong to it. Instead, a resolver evaluating DNSSEC must start its validation journey with a root public key—or its associated fingerprint—that it has been pre-configured to trust. In cryptography, this foundational starting point is known as a trust anchor.
The signing keys managed at the root level are divided into two distinct operational roles. The zone-signing key is responsible for signing the root’s everyday DNS records, which includes the DS records for top-level domains like .com. Meanwhile, the key-signing key holds the weightier responsibility of signing the entire list of public keys published by the root, known formally as the DNSKEY record set. A validating resolver uses its pre-configured, trusted KSK to verify that specific list, and subsequently utilizes the ZSK from that same verified list to check all other records originating from the root.
In a typical signed domain zone, trust flows downward from a parent. For the absolute root of the DNS, however, trust cannot rely on a parent zone; instead, it stems entirely from the trust anchor embedded within the resolver software itself.
Past incidents involving top-level domain rollovers, such as those that affected the .de and .al zones, vividly demonstrated the real-world consequences of failed DNSSEC checks. When validation fails, websites that are otherwise operating normally can become completely unreachable to end users. Because the root KSK rollover changes the absolute starting point of the entire cryptographic chain, if a resolver fails to trust the replacement key, its users may find themselves entirely unable to reach websites residing under any top-level domain whatsoever.
The incoming replacement key is formally designated as KSK-2024, identifiable by the key tag 38696. It is scheduled to replace the aging KSK-2017, which bears the key tag 20326, as the primary signer of the root’s DNSKEY set. Validating resolvers across the globe must fully trust this new key prior to the activation date.
How Resolvers Acquire the New Root Key
The technical process for distributing and adopting a new root trust anchor is governed by RFC 5011, a standard that enables resolvers to learn new root trust anchors automatically. Under this protocol, the root zone publishes the new KSK right alongside the existing, active key within its DNSKEY set. Because the older KSK continues signing the record set during the transition period, a resolver can leverage the key it already implicitly trusts to cryptographically verify the records containing the replacement.
Before accepting a newly discovered key as a permanent trust anchor, a standard RFC 5011-compliant resolver enforces a safety waiting period of at least 30 days. Throughout this window, the resolver continuously monitors the root’s signed DNSKEY records to ensure the new key remains present. Once the mandatory waiting period elapses, the resolver must successfully verify the records containing the new key one final time before formally adding it to its internal trust store.
For the current rollover event, KSK-2024 has been actively published within the root’s DNSKEY set since January 11, 2025. This extended timeline provided resolvers utilizing automatic trust-anchor updates ample opportunity to discover, observe, and accept the key well ahead of the scheduled October 11, 2026 signing change. Each individual resolver’s waiting period officially begins the moment it first encounters and successfully verifies the new key.
In the case of infrastructure providers like Cloudflare, engineers took a more direct approach. KSK-2024 was hardcoded directly into the resolver software’s built-in trust anchors as early as July 2024, sitting alongside the existing KSK-2017. Consequently, any resolver running the updated software package possesses the new trust anchor natively from the moment of startup, bypassing the need to wait for runtime discovery.
This proactive approach was chosen specifically to mitigate risks identified during preparations for the first historic rollover in 2018. As operational logs from that era indicated, unexpected software updates, system reboots, and routine migrations between hardware instances occasionally caused resolvers to lose their dynamically learned trust-anchor states. By baking the new anchor directly into the default software distribution, operators can successfully avoid relying entirely on each individual resolver’s ability to retain a key it discovered automatically over the network.
Even with KSK-2024 embedded directly into resolver trust anchors months in advance, everyday users utilizing public services like 1.1.1.1 and Gateway DNS previously lacked a direct, user-friendly method to verify whether the specific backend resolver answering their queries actually recognized and trusted the new key.
Querying the Resolver Directly
To bridge this visibility gap, internet engineers established RFC 8509, which defines the root key trust anchor sentinel. This ingenious protocol provides a standardized way to ask a supporting resolver whether it currently trusts a particular root key, utilizing ordinary DNS queries directed at specially constructed domain names.
Readiness testing websites leverage this exact protocol to check for the presence of KSK-2024. The mechanism employs paired domain names that pose opposite questions: one queries whether a specific key tag is trusted, while the other asks whether it is explicitly untrusted. Both names feature valid, DNSSEC-signed address records. A resolver that fully supports the sentinel standard will first validate those records and then either return a normal response directly or deliberately replace the answer with a SERVFAIL status code, depending entirely on whether it holds trust in the queried key.
For a properly functioning validating resolver with full sentinel support, encountering a SERVFAIL response for the "not trusted" query is the expected and correct behavior when the key is trusted, as the resolver is intentionally rejecting the premise that the key is absent. These specialized sentinel labels can be appended beneath any DNSSEC-signed domain.
In addition to testing sentinel behavior, comprehensive readiness checks also confirm 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 rigorous control checks help distinguish a meaningful diagnostic result from a routine lookup failure or an unsupported protocol. If a resolver’s support for the sentinel standard cannot be definitively established, the test result is classified as inconclusive rather than implying the new key is missing.
While browser-based tests automatically evaluate the resolver currently utilized by a web browser—which may be influenced by local Secure DNS settings or corporate VPN configurations—advanced administrators can also query specific resolvers directly using command-line diagnostic utilities like dig to gain a precise snapshot of the query path.
A New Key While Retaining Familiar Algorithms
Both KSK-2017 and the incoming KSK-2024 rely on the RSA/SHA-256 cryptographic algorithm. This means the upcoming rollover represents a straightforward replacement of the underlying key pair while maintaining the identical mathematical method for generating and verifying digital signatures.
During discussions surrounding the first root key rollover in industry forums, experts noted that a successful execution would eventually pave the way for discussions regarding a broader algorithm transition. Yet, nearly a decade later, the DNS root infrastructure continues to rely on RSA.
Nevertheless, periodically replacing the cryptographic key remains a vital operational necessity. Routine rollovers limit the lifespan of any single private signing key and thoroughly exercise the logistical machinery required to distribute new trust anchors, update global resolver software, and safely retire legacy keys. As the inaugural rollover demonstrated, those operational steps can occasionally encounter failure even when the underlying cryptography functions precisely as intended.
The Internet Assigned Numbers Authority maintains an idealized three-year rollover interval, striking a careful balance between establishing regular operational practice and minimizing the ongoing workload and inherent risks associated with altering the root key too frequently. The extended gap separating the 2018 event from the upcoming 2026 transition was largely attributed to pandemic-related disruptions and necessary hardware upgrades applied to the highly secure hardware security modules that safeguard the root’s private signing keys.
Transitioning to an entirely different cryptographic algorithm in the future will require resolvers to possess both a new trust anchor and upgraded software capable of parsing and verifying unfamiliar signature formats. By conducting regular key rollovers with familiar algorithms, operators can thoroughly test the trust-anchor distribution pipeline without introducing additional cryptographic variables.
Looking Beyond the October Milestone
The October 11 switch marks the definitive moment when the new KSK begins signing the root’s DNSKEY set, but the broader lifecycle of the rollover will extend well into 2027. During the subsequent phase, ICANN plans to formally revoke KSK-2017, remove it entirely from the active root zone, and securely destroy its private signing key. Industry standards emphasize that stopping a key from actively signing records and entirely revoking trust in that key remain two distinct, sequential operational steps.
Looking further ahead, ICANN has also published preliminary proposals exploring a future root algorithm rollover to ECDSA P-256. ECDSA algorithms naturally produce significantly smaller public keys and digital signatures than the traditional RSA standard used across the root infrastructure today. However, that prospective proposal remains entirely separate from the upcoming October key replacement, and ECDSA itself is not a post-quantum cryptographic algorithm.
Simultaneously, the broader cybersecurity community is preparing for the post-quantum era. Resolver infrastructure like 1.1.1.1 has already introduced experimental validation for ML-DSA-44 signatures, which are specifically engineered to remain secure against advanced attacks mounted by future quantum computers. For the entire DNSSEC chain of trust to achieve post-quantum security, individual signed domains, their parent zones, and the ultimate root must all eventually adopt post-quantum cryptography. At the root level, this transformation will necessitate introducing a post-quantum KSK and ensuring that validating resolvers worldwide are prepared to trust it.
Achieving that future milestone will ultimately demand yet another root key rollover. The routine rollovers performed today give network operators invaluable opportunities to test how effectively replacement trust anchors are distributed, confirm that validating resolvers have successfully accepted them, and practice retiring legacy keys. While this October’s rollover retains the familiar RSA standard, it serves as a crucial operational drill for the trust-anchor updates that will inevitably be required when the root eventually transitions to post-quantum cryptography, with sentinel protocols providing the vital visibility needed to verify resolver readiness.
In the meantime, internet service providers and resolver developers are strongly encouraged to implement support for RFC 8509 trust anchor sentinels. Ensuring that end users have a reliable, transparent way to check whether their chosen resolver trusts the upcoming root key before a major cryptographic transition takes place remains a shared responsibility across the global networking community.
For network administrators and operators, the immediate focus remains squarely on the October 11 deadline. Organizations operating DNSSEC-validating resolvers are advised to confirm that their software systems are fully prepared to trust KSK-2024 and to consult official guidance from ICANN and software vendors if any updates are required.
Leave a Reply