DNS Root Key-Signing Key Scheduled for Rollover on October 11, 2026

DNS Root Key-Signing Key Scheduled for Rollover on October 11, 2026 The DNS root is scheduled to conduct only its second-ever key-signing key (KSK) rollover on October 11, 2026, transitioning from KSK-2017 to KSK-2024. DNSSEC-validating resolvers must ensure trust in the new key prior to the switch to prevent healthy domains from becoming unreachable. On October 11, 2026, root signing transitions to KSK-2024 (key tag 38696), replacing KSK-2017 (key tag 20326). Resolvers failing to trust the new trust anchor will cause validation failures, rendering websites across any top-level domain unreachable. Cloudflare implemented RFC 8509 sentinel tests at dnstest.dev to let users verify if their resolvers trust the new key. Both current and replacement keys rely on RSA/SHA-256, but the procedure exercises operational processes needed for future ECDSA and post-quantum algorithm transitions. Root Trust Anchors and the Rollover Schedule The DNS root serves as the trust anchor for DNSSEC validation because it lacks a parent zone to certify its keys. Its key-signing key (KSK) validates the root's DNSKEY record set, which contains the zone-signing key (ZSK) used to sign top-level domain delegation records. On October 11, 2026, the root will switch its signing key to KSK-2024 (tag 38696), replacing KSK-2017 (tag 20326). If a validating resolver lacks trust in KSK-2024 when the signing switch occurs, DNSSEC validation will fail across all top-level domains. ICANN plans to complete the retirement by revoking KSK-2017 and deleting its private key in 2027. Key Distribution and Operational Precautions Under RFC 5011, resolvers can learn new trust anchors dynamically: KSK-2024 has been published alongside the existing key in the root DNSKEY set since January 11, 2025, requiring resolvers to observe it for at least 30 days before acceptance. However, operational experience from the 2018 rollover revealed that software upgrades and host migrations often wiped dynamic trust-anchor state. Consequently, Cloudflare embedded KSK-2024 directly into 1.1.1.1's built-in software trust anchors in July 2024, eliminating reliance on autonomous state persistence. Verification via RFC 8509 Sentinels To verify resolver trust in the new key, Cloudflare introduced an online testing tool based on RFC 8509 Root Key Trust Anchor Sentinels. The sentinel mechanism queries dedicated labels under a signed domain: queries containing 'is-ta-38696' return valid DNS answers if the resolver trusts KSK-2024, whereas queries with 'not-ta-38696' deliberately trigger a SERVFAIL response. These control checks allow operators to verify whether validating resolvers are prepared without breaking general resolution. Significance for Future Algorithm and Post-Quantum Transitions Both KSK-2017 and KSK-2024 utilize RSA/SHA-256. Although IANA targets a three-year rollover cadence, this cycle experienced delays attributed by ICANN to pandemic disruptions and cryptographic hardware upgrades. Maintaining regular rollovers validates distribution and retirement mechanisms in isolation from cryptographic changes. These rehearsals are critical precursors to ICANN's proposed migration to ECDSA P-256 and eventual post-quantum signature schemes such as ML-DSA-44.

DNS根区密钥轮换定于10月11日：验证机制与应对准备 DNS根区计划于2026年10月11日迎来历史上第二次密钥签名密钥（KSK）轮换，由新密钥KSK-2024替代KSK-2017。DNSSEC验证解析器需提前信任新密钥，否则可能导致所有顶级域名下的正常网站均无法访问。 DNS根区预定于2026年10月11日进行史上第二次KSK轮换，以KSK-2024（密钥标签38696）替代KSK-2017（密钥标签20326）。 解析器若未及时信任新根密钥，将导致DNSSEC验证链断裂并使健康网站无法解析；普通网站运营者和Cloudflare解析器用户无需操作。 RFC 5011支持自动学习新密钥，但此前曾发生因机器迁移或升级导致状态丢失的情况，Cloudflare已于2024年7月将新密钥内置到解析器。 基于RFC 8509的哨兵机制可通过特定域名查询测试解析器是否信任KSK-2024；本次轮换沿用RSA/SHA-256算法，为未来的ECDSA及后量子密码迁移演练流程。 根KSK轮换机制与信任风险 根密钥签名密钥（KSK）作为DNSSEC信任链的根基，负责对根区DNSKEY集合进行签名，解析器据此自上而下验证顶级域及下级域名的签名。若验证解析器未更新根信任锚，转换后会导致用户无法访问任何顶级域下的网站。本次新密钥KSK-2024自2025年1月11日起已发布在根区记录中供解析器发现。 更新方式与哨兵就绪测试 虽然RFC 5011允许解析器在至少30天的等待期后自动学习并接受新信任锚，但历史经验显示软件升级或机器迁移容易导致已学状态丢失。为此Cloudflare直接在软件内置新密钥。同时，Cloudflare部署了基于RFC 8509信任锚哨兵协议的测试工具，通过is-ta-38696和not-ta-38696等特定域名查询，帮助用户验证解析器是否已建立对新密钥的信任。 轮换意义与后续演进 本次轮换延续了RSA/SHA-256算法，未改变签名方式，主要作用在于限制单套私钥的使用寿命并演练分发流程；因疫情和硬件升级延期后，ICANN计划在2027年撤销并销毁KSK-2017。此外，ICANN提出了向ECDSA P-256演进的算法轮换方案，未来若引入抗量子攻击的后量子密码学签名（如ML-DSA-44），也仍需依赖根密钥轮换流程。

On October 11, 2026, the DNS root is scheduled to change its key-signing key (KSK) for only the second time ever. This key anchors DNSSEC’s chain of trust, which lets DNS resolvers authenticate answers using cryptographic signatures. The change is called a KSK rollover. Validating resolvers need to trust the new key before the switch, as otherwise healthy websites could become unreachable. When we [wrote about the first root KSK rollover in 2018](https://blog.cloudflare.com/its-hard-to-change-the-keys-to-the-internet-and-it-involves-destroying-hsms/), we had seen resolvers lose their learned trust in the new key during software upgrades or moves between machines. Publishing the key well in advance was only part of the job. We also needed to know whether resolvers had retained it, and we couldn’t give users a practical way to check. Most website operators do not need to make any changes for this rollover. If you run a DNSSEC-validating resolver, check that it trusts the new root key, KSK-2024, and follow your software vendor’s instructions to update its trust anchors if the key is missing. If you use Cloudflare for your domain's DNS or rely on 1.1.1.1 and Gateway DNS, you do not need to take any action — our systems already trust KSK-2024. To check ahead of time, visit our [rollover readiness test](https://dnstest.dev/ksk-2024/). It asks the resolver your browser uses whether it trusts the new key. The test uses [RFC 8509: A Root Key Trust Anchor Sentinel for DNSSEC](https://datatracker.ietf.org/doc/html/rfc8509), which we’ve implemented in 1.1.1.1 ahead of the rollover. A DNS resolver looks up the addresses of websites and other services for your device. DNSSEC lets it check digital signatures on DNS records to verify that they are authentic and have not been changed. The resolver also needs to check that the public keys used to verify those signatures belong to the right domains. For `cloudflare.com`, this follows a chain of trust from the DNS root to `.com`, then to `cloudflare.com`. Each parent publishes a Delegation Signer (DS) record containing a fingerprint of its child’s public key. For example, `.com` publishes the DS record for `cloudflare.com`, allowing the resolver to check that domain’s key. That chain needs a starting point. The root, however, has no parent to confirm which keys belong to it. Instead, a resolver checking DNSSEC starts with a root public key, or its fingerprint, that it already trusts. This is called a trust anchor. The root’s signing keys have two different jobs. The zone-signing key (ZSK) signs the root’s DNS records, including the DS records for top-level domains such as `.com`. The key-signing key (KSK) signs the list of public keys published by the root, called the DNSKEY record set. The resolver uses its trusted KSK to verify that list, then uses the ZSK from the list to verify the root’s other records. The diagram below shows the arrangement for a typical signed zone. For the root, trust comes from the resolver’s trust anchor rather than a DS record in a parent zone. Our posts about the [.de](https://blog.cloudflare.com/de-tld-outage-dnssec/) and the [.al](https://blog.cloudflare.com/dnssec-nta-ede-33/) rollover failures showed the consequence of failed DNSSEC checks: websites can be working normally but still be unreachable. The root KSK rollover changes the starting point of those checks. If a resolver does not trust the replacement key, its users may be unable to reach websites under **any** top-level domain. The new key is [KSK-2024](https://www.icann.org/resources/pages/ksk-rollover-en), identified by key tag `38696`. It will replace KSK-2017, key tag `20326`, as the signer of the root’s DNSKEY set. Validating resolvers need to trust the new key before that switch. [RFC 5011](https://datatracker.ietf.org/doc/html/rfc5011) lets resolvers learn a new root trust anchor automatically. The root publishes the new KSK alongside the existing one in its DNSKEY set. The existing KSK continues signing that set, so a resolver can use the key it already trusts to verify the records containing the replacement. Before accepting the new key as a trust anchor, the resolver waits at least 30 days and keeps checking the root’s signed DNSKEY records. The new key must remain in the records it checks during that period. After the wait, the resolver must successfully verify the records containing the new key again before accepting it. For this rollover, [KSK-2024 has been published in the root’s DNSKEY set since January 11, 2025](https://www.iana.org/dnssec/files). That gave resolvers with automatic trust-anchor updates time to discover and accept it ahead of the scheduled October 11, 2026 signing change. Each resolver’s waiting period starts when it first sees and verifies the new key. For our resolver, we added KSK-2024 directly to the software’s built-in trust anchors in July 2024, alongside KSK-2017. A resolver running the updated software therefore has the new anchor available from startup. We chose this approach because of our experience during preparations for the first rollover. As described in [our 2018 post](https://blog.cloudflare.com/its-hard-to-change-the-keys-to-the-internet-and-it-involves-destroying-hsms/#operational-reality-vs-the-protocol-design), software upgrades and moves between machines caused some resolvers to lose their learned trust-anchor state. We fixed that by updating the software to include the new anchor by default. Including KSK-2024 in the software likewise avoids depending on each resolver retaining a key it learned automatically. Even though we added KSK-2024 to our resolver’s built-in trust anchors in July 2024, users of 1.1.1.1 and [Gateway DNS](https://www.cloudflare.com/products/gateway/) had no direct way to check whether the resolver answering their queries trusted the new key. [RFC 8509](https://datatracker.ietf.org/doc/html/rfc8509) defines the root key trust anchor sentinel, a way to ask a supporting resolver whether it trusts a particular root key. It uses ordinary DNS queries with specially named domains. [Our readiness test website](https://dnstest.dev/ksk-2024/) uses this protocol to check for KSK-2024. Two names ask opposite questions: `is-ta-38696` asks whether the key is trusted, `not-ta-38696` asks whether it is not trusted. Both names have valid DNSSEC-signed address records. A resolver that supports the sentinel first validates those records, then either returns the response directly or replaces the answer with `SERVFAIL`, depending on whether it trusts the key. For a validating resolver with sentinel support, the expected results are: | Query | KSK-2024 is trusted | KSK-2024 is not trusted | | `is-ta-38696` | Returns a valid response | Returns `SERVFAIL` | | `not-ta-38696` | Returns `SERVFAIL` | Returns a valid response | For a validating resolver with sentinel support, `SERVFAIL` for `not-ta-38696` is expected when KSK-2024 is trusted. The resolver deliberately rejects the “not trusted” query. Sentinel labels such as `root-key-sentinel-is-ta-38696` can be used under any DNSSEC-signed domain. We use `dnstest.dev` for our tests. You can run the two queries directly against 1.1.1.1: ``` $ dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer ; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44476 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; ANSWER SECTION: root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.6.197 root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.7.197 $ dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer ; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3285 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ``` The website also checks that an ordinary signed name resolves, that a deliberately invalid DNSSEC name is rejected, and that the resolver responds to a sentinel query for the current root key. These controls help distinguish a meaningful result from a failed lookup or unsupported protocol. If sentinel support cannot be established, the result is inconclusive; it does not mean the new key is missing. The browser test checks the resolver your browser uses, which may be affected by Secure DNS or a VPN. The `dig` commands above explicitly query 1.1.1.1. Both provide a snapshot of the resolver path answering those requests. KSK-2017 and KSK-2024 both use RSA/SHA-256. The rollover replaces the key pair while keeping the same method for creating and verifying signatures. In [our 2018 post](https://blog.cloudflare.com/its-hard-to-change-the-keys-to-the-internet-and-it-involves-destroying-hsms/#why-are-we-rolling-the-root-key-trust-anchor), we wrote that a successful rollover would open the door to discussing an algorithm change. Eight years later, the root still uses RSA. Replacing the key remains useful. It limits how long a single private key stays in use and exercises the process of distributing new trust anchors, updating resolvers, and retiring old keys. As the first rollover showed, those steps can fail even when the cryptography itself works correctly. [The Internet Assigned Numbers Authority (IANA) plans an idealized three-year rollover interval](https://www.iana.org/dnssec/files), balancing regular practice against the work and risk of changing the root key too frequently. The gap since 2018 has been longer. [The Internet Corporation for Assigned Names and Numbers (ICANN) attributes the delay](https://www.icann.org/en/blogs/details/preparing-for-the-root-zone-ksk-rollover-what-you-need-to-know-27-07-2026-en) to pandemic disruption and upgrades to the hardware that protects the private signing keys. Changing algorithms means resolvers need both a new trust anchor and software that can verify the new signatures. Regular key rollovers let operators test the trust-anchor updates while keeping the algorithm the same. The October 11 switch changes which KSK signs the root’s DNSKEY set. The rollover continues into 2027, when [ICANN plans to revoke KSK-2017, remove it from the root zone, and delete its private key](https://www.icann.org/en/system/files/files/root-zone-ksk-rollover-faq-22may26-en.pdf). Stopping a key from signing and removing trust in that key are separate steps. ICANN has also [proposed a future root algorithm rollover to ECDSA P-256](https://itp.cdn.icann.org/en/files/domain-name-system-dns-engineering/proposal-for-root-zone-ksk-algorithm-rollover-03-02-2026-en.pdf). [ECDSA](https://www.cloudflare.com/learning/dns/dnssec/ecdsa-and-dnssec/) produces smaller keys and signatures than the RSA algorithm used today. That proposal is separate from this October’s key replacement, and ECDSA is not a post-quantum algorithm. [1.1.1.1 now validates ML-DSA-44 signatures](https://blog.cloudflare.com/post-quantum-dnssec-1111/), which are designed to remain secure against attacks using quantum computers. For DNSSEC’s whole chain of trust to become post-quantum secure, signed domains, their parent zones, and the root must adopt post-quantum cryptography too. At the root, that means introducing a post-quantum KSK and getting resolvers to trust it. That will require another root key rollover. The rollovers we perform now let operators test how they distribute replacement trust anchors, check that resolvers have accepted them, and retire the old keys. This October’s rollover keeps RSA, but exercises the trust-anchor updates we will need when the root moves to post-quantum cryptography. The sentinel gives us a way to check whether resolvers followed those updates. We encourage DNS providers and resolver developers to support [RFC 8509 trust anchor sentinels](https://datatracker.ietf.org/doc/html/rfc8509). If your resolver does not support them, ask your provider or software vendor to add support. Users should be able to check whether their resolver trusts the next root key before a rollover. For now, the next deadline is October 11. You can check your resolver’s readiness at [https://dnstest.dev/ksk-2024](https://dnstest.dev/ksk-2024). If you operate a DNSSEC-validating resolver, confirm that it trusts KSK-2024, key tag `38696`, and follow [ICANN’s guidance](https://www.icann.org/resources/pages/ksk-rollover-en) and your software vendor’s instructions if the key is missing.