--- url: "https://www.xcademia.com/news/dns-root-key-rollover-set-for-october-11-what-operators-need-to-know" title: "DNS Root Key Rollover Set for October 11: What Operators Need to Know" description: "The DNS root KSK rollover happens October 11, 2026. Learn about KSK-2024, DNSSEC trust anchors and what resolver operators need to check." publishedAt: "2026-10-07T10:55:16.397+00:00" updatedAt: "2026-10-12T01:29:04.075998+00:00" type: news category: cybersecurity source_name: Cloudflare Blog source_url: "https://blog.cloudflare.com/root-ksk-2024-rollover/" tags: - "#DNSSEC" - "#Cybersecurity" - "#DNS" - "#Cryptography" - "#InternetSecurity" - "#InfrastructureSecurity" - "#CloudSecurity" - "#PostQuantumSecurity" --- # DNS Root Key Rollover Set for October 11: What Operators Need to Know > The DNS root will switch to a new key-signing key on October 11, 2026. Cloudflare explains why DNSSEC resolvers must trust KSK-2024 and how operators can test their readiness before the rollover. Source: **Cloudflare Blog** · 7 October 2026 The DNS root is scheduled for an important cryptographic change on **October 11, 2026**, when the Internet's root zone will switch to a new key-signing key, known as **KSK-2024**. The change is only the **second root KSK rollover ever**. The first took place in 2018. While most website operators will not need to make changes, organisations operating DNSSEC-validating resolvers need to ensure that their systems trust the replacement key before the switch. The issue is not that websites are being modified or that domain records are being replaced. The change affects the cryptographic starting point that validating DNS resolvers use to establish trust in the DNS hierarchy. If a validating resolver does not recognise the new key, DNSSEC validation can fail. In that situation, otherwise healthy websites can become unreachable for users relying on that resolver. ## What Is the DNS Root KSK? The Domain Name System, or DNS, translates domain names into information such as IP addresses. DNSSEC adds cryptographic validation so that resolvers can verify that DNS information has not been tampered with. DNSSEC works through a chain of trust. For example, validation for `cloudflare.com` starts at the DNS root, continues through the `.com` top-level domain and eventually reaches the domain itself. The DNS root has no parent from which it can inherit trust. Instead, validating resolvers start with a preconfigured **trust anchor**, which contains the root's trusted public key information. The root uses two important types of signing keys: - **Key-signing key (KSK):** Signs the DNSKEY record set containing the root's public keys. - **Zone-signing key (ZSK):** Signs the root's DNS records, including Delegation Signer records for top-level domains. The KSK therefore plays a particularly important role because it establishes the initial cryptographic trust in the root's DNSKEY information. ![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1791370441978-info1--113-.webp) ## KSK-2024 Will Replace KSK-2017 The new root key is **KSK-2024**, identified by key tag **38696**. It will replace **KSK-2017**, which has key tag **20326**, as the signer of the root's DNSKEY set. DNSSEC-validating resolvers need to trust KSK-2024 before the October 11 change. Cloudflare notes that KSK-2024 has been published in the root DNSKEY set since **January 11, 2025**. This provides resolvers using automatic trust-anchor updates with time to discover and accept the replacement key. The rollover does not introduce a new cryptographic algorithm. Both KSK-2017 and KSK-2024 use **RSA/SHA-256**. That distinction is important. This October's event is a key replacement, not an algorithm migration. ## How Resolvers Can Learn the New Key Automatically The DNS root uses **RFC 5011** to support automatic trust-anchor updates. Under this mechanism, a resolver can see the new KSK published alongside the existing key. Because the existing trusted KSK continues signing the DNSKEY set, the resolver can validate the information containing the replacement key. Before accepting the new key as a trust anchor, the resolver waits at least **30 days** and continues checking the signed DNSKEY records. The new key must remain present throughout the process before the resolver accepts it. This creates an important operational dependency. Automatic key learning only works reliably if the resolver retains the learned trust-anchor state and continues validating the root correctly. Cloudflare says its experience from the 2018 rollover showed that software upgrades and migrations between machines could cause some resolvers to lose their learned trust-anchor state. For its own resolver, Cloudflare therefore added KSK-2024 directly to its software's built-in trust anchors in July 2024, alongside KSK-2017. ## Why DNSSEC Failures Can Make Websites Unreachable A DNSSEC failure does not necessarily mean that the website's server is offline. The underlying website can be operating normally while a validating resolver refuses to return its DNS information because the cryptographic chain cannot be validated. Cloudflare points to previous DNSSEC rollover failures involving the `.de` and `.al` top-level domains as examples of how broken validation can affect availability. For the root KSK rollover, the potential scope is broader because the root is the starting point for the DNSSEC chain. If a resolver fails to trust KSK-2024 after KSK-2017 becomes the old key, DNSSEC validation could fail for domains across different top-level domains. This is why resolver operators need to treat trust-anchor readiness as an operational requirement rather than simply a cryptographic update. ![info-2](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1791370459165-info2--114-.webp) ## Cloudflare Adds a Readiness Test One of the practical improvements described by Cloudflare is a way to check whether a resolver trusts KSK-2024. The mechanism uses **RFC 8509**, which defines a Root Key Trust Anchor Sentinel for DNSSEC. Cloudflare's readiness test uses specially constructed DNS queries to ask a supporting resolver whether it trusts a particular root key. For KSK-2024, the test uses key tag **38696**. Two sentinel names are used: - `is-ta-38696` - `not-ta-38696` A validating resolver that supports the sentinel responds differently depending on whether it trusts KSK-2024. If KSK-2024 is trusted: - `is-ta-38696` returns a valid response. - `not-ta-38696` returns `SERVFAIL`. The `SERVFAIL` response in the second case is expected because the resolver is deliberately rejecting the query that asks it to behave as though KSK-2024 is not trusted. Cloudflare says users can use its readiness test at **dnstest.dev/ksk-2024** to check the resolver used by their browser. ## What Organisations Need to Do For most ordinary website operators, **no action is required**. Cloudflare says customers using Cloudflare for authoritative DNS, as well as users relying on **1.1.1.1 and Gateway DNS**, do not need to take action because those systems already trust KSK-2024. The situation is different for organisations that operate their own DNSSEC-validating resolvers. They should: 1. Confirm that the resolver trusts **KSK-2024**. 2. Verify that the key tag is **38696**. 3. Follow the relevant DNS software vendor's instructions if the key is missing. 4. Use a readiness test where supported. 5. Ensure resolver software retains trust-anchor information through upgrades and infrastructure changes. The company did not provide specific information about every DNS resolver implementation or software configuration that may require manual intervention. ## The Rollover Continues Beyond October 11 October 11 is the critical signing change, but it is not the end of the overall rollover process. Cloudflare explains that ICANN plans to revoke KSK-2017 in **2027**, remove it from the root zone and delete its private key. Stopping a key from signing and removing trust in that key are separate operational steps. This distinction matters because cryptographic key lifecycle management does not end when a replacement key begins signing. ## Why This Rollover Matters for Future Cryptography The current rollover also provides an opportunity to test the infrastructure required for future changes. KSK-2024 continues to use RSA/SHA-256, so this event does not represent a move to a different signature algorithm. However, Cloudflare notes that ICANN has proposed a future root algorithm rollover to **ECDSA P-256**. That proposal is separate from the October 2026 KSK replacement. Cloudflare also discusses the longer-term challenge of post-quantum DNSSEC. Its 1.1.1.1 resolver now validates **ML-DSA-44** signatures, but making the complete DNSSEC chain post-quantum secure would require the signed domains, parent zones and root to adopt appropriate post-quantum cryptography. That future transition would require another root key rollover. The current rollover therefore has relevance beyond replacing one RSA key. It provides an operational exercise in distributing trust anchors, verifying that resolvers have accepted them and eventually retiring the previous key. ![info-3](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1791370496159-info3--113-.webp) ## What This Means for Internet Reliability The October 2026 root KSK rollover highlights an often overlooked part of Internet infrastructure: **trust management is just as important as cryptographic algorithms themselves**. A new key can be cryptographically sound, but resolvers still need to receive, retain and trust that key correctly. The experience of the 2018 rollover demonstrated that software upgrades and infrastructure migrations can affect trust-anchor state. The current process places additional emphasis on being able to verify resolver readiness before the actual signing transition. For enterprises operating DNS infrastructure, this reinforces the importance of treating DNSSEC configuration as part of operational resilience. **The announcement highlights a broader industry shift toward making cryptographic infrastructure more observable and testable.** A mechanism such as the RFC 8509 trust-anchor sentinel gives operators a way to verify an important part of DNSSEC readiness rather than relying entirely on assumptions about resolver configuration. ## Key Takeaways - The DNS root is scheduled to switch to **KSK-2024 on October 11, 2026**. - KSK-2024 has key tag **38696**. - It will replace KSK-2017, key tag **20326**, as the signer of the root DNSKEY set. - Both keys use **RSA/SHA-256**. - Most website operators do not need to make changes. - DNSSEC-validating resolver operators should verify that KSK-2024 is trusted. - RFC 5011 supports automatic trust-anchor updates. - RFC 8509 provides a mechanism for testing whether a resolver trusts a particular root key. - KSK-2017 is planned for revocation and removal in 2027. - The current rollover also exercises processes that could become important during future algorithm and post-quantum DNSSEC transitions. ## Original Analysis The significance of this event is less about an immediate change for everyday website visitors and more about the resilience of the infrastructure underneath DNSSEC. The rollover demonstrates that cryptographic key management involves several operational layers: distributing new trust anchors, retaining them across software and infrastructure changes, validating their presence and eventually retiring the previous key. For enterprises, this could mean that DNSSEC readiness should be considered alongside broader infrastructure lifecycle management, particularly when resolvers are migrated, upgraded or rebuilt. The development also reflects growing demand for **verifiable cryptographic readiness**. Rather than simply publishing a replacement key and expecting systems to adopt it, the RFC 8509 sentinel approach provides a mechanism for checking whether supporting resolvers have accepted the new trust anchor. ## Original source https://blog.cloudflare.com/root-ksk-2024-rollover/ ## Tags `#DNSSEC` · `#Cybersecurity` · `#DNS` · `#Cryptography` · `#InternetSecurity` · `#InfrastructureSecurity` · `#CloudSecurity` · `#PostQuantumSecurity` --- ## About this content This Markdown news article is the citation-grade twin of [DNS Root Key Rollover Set for October 11: What Operators Need to Know](https://www.xcademia.com/news/dns-root-key-rollover-set-for-october-11-what-operators-need-to-know). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite. When citing or quoting, please attribute *Xcademia* and link back to the source URL above. - Source: https://www.xcademia.com/news/dns-root-key-rollover-set-for-october-11-what-operators-need-to-know - Publisher: Xcademia, https://www.xcademia.com - Catalogue index: https://www.xcademia.com/llms-full.txt