DNS root KSK-2024 takes over signing on 11 October 2026

On 11 October 2026 the DNS root is scheduled to sign its key set with a new key-signing key. IANA’s trust-anchor page sets that date and says the current key will not sign the zone afterward. Cloudflare’s briefing of 6 October 2026, by Sebastiaan Neuteboom and James Godlewski, is the operator account this brief follows. IANA lists KSK-2017, key tag 20326, as the active signer since 11 October 2018. This is the second root KSK rollover.

What a KSK rollover changes

DNSSEC lets a validating resolver check signatures on DNS data. Cloudflare traces a name such as cloudflare.com from the root to .com to the domain. Each parent publishes a DS record, a fingerprint of the child’s key. The root has no parent. The resolver starts from a trust anchor it already holds. IANA calls that anchor the root key-signing key.

The zone-signing key signs the root’s records, including DS records for top-level domains. The key-signing key signs the DNSKEY set, the root’s published public keys. A rollover replaces the key-signing key. The zone-signing key is not the key that changes on 11 October.

On the IANA table as read 6 October 2026, KSK-2024 is Pre-Publication, key tag 38696, and is expected to supersede KSK-2017. The trust-anchor XML marks tags 20326 and 38696 as algorithm 8. IANA’s algorithm registry names algorithm 8 RSA/SHA-256. Cloudflare says this October switch keeps that algorithm.

If a validating resolver misses the new key, Cloudflare says its users may be unable to reach sites under any top-level domain, including sites that are otherwise healthy. ICANN’s 27 July 2026 post says that network would see total DNS resolution failures. Neither source gives a count of users or resolvers.

Who has to act

Cloudflare says most website operators need no change. ICANN’s May 2026 FAQ says a smooth rollover brings no perceptible change for end users. Operators of DNSSEC-validating resolvers are the exception. IANA says they need an updated trust anchor to keep validating the root. The tag to find is 38696.

ICANN tells them to open the trust-anchor file rather than assume RFC 5011 updated it. The July post names bind.keys for BIND, root.key for Unbound and PowerDNS Recursor, and root.keys for Knot Resolver. If 38696 is missing, check that automatic updates are on and that the resolver can write its key store.

Cloudflare says its domain DNS, 1.1.1.1, and Gateway DNS already trust KSK-2024, so those customers have nothing to do. On 6 October 2026 a query to 1.1.1.1 for root-key-sentinel-is-ta-38696.dnstest.dev returned NOERROR with the AD flag, and root-key-sentinel-not-ta-38696.dnstest.dev returned SERVFAIL. That pair matches the trusted-key row in Cloudflare’s RFC 8509 table. It is a snapshot of 1.1.1.1. Gateway DNS and Cloudflare’s authoritative DNS were not queried, so their readiness remains Cloudflare’s statement.

How the new key is learned

RFC 5011 lets a resolver accept a new root trust anchor after watching it, signed by the current key, for at least 30 days. IANA dates publication of the successor to 11 January 2025, and 10 February 2025 as the day those resolvers should start trusting it. The July ICANN post and Cloudflare use the same 11 January 2025 publication date.

The May FAQ says publication was February 2025, and it labels phase D February 2025. That month conflicts with IANA, the July ICANN post, and Cloudflare. This brief uses 11 January 2025.

Cloudflare says it put KSK-2024 into its resolver’s built-in trust anchors in July 2024, next to KSK-2017, because the 2018 rollover showed that upgrades and machine moves can drop a learned key. The XML validFrom for tag 38696 is 18 July 2024. That date belongs to the trust-anchor file, not to a Cloudflare software release.

A readiness check

Cloudflare’s test is https://dnstest.dev/ksk-2024. The page answered HTTP 200 on 6 October 2026. It asks the resolver the browser is using, which Secure DNS or a VPN can replace. The sentinel names are is-ta-38696 and not-ta-38696. When the resolver supports the sentinel and trusts the key, SERVFAIL on the “not trusted” name is expected. If the test cannot show sentinel support, Cloudflare says the result is inconclusive, which does not mean the key is missing.

Same algorithm, then 2027

IANA plans an idealized three-year gap between rollovers. The gap since 2018 is longer. ICANN’s July post attributes the slip to remote-only key ceremonies during the pandemic and to a later swap of the hardware security modules that hold the private key. That swap is why the successor is KSK-2024.

October keeps RSA/SHA-256. An algorithm change is a later plan. ICANN’s public comment on a root KSK algorithm rollover opened on 3 February 2026 and is closed. The page says the October 2026 rollover still uses RSA with SHA-256, and that ICANN org will proceed with the proposed algorithm rollover. The call for comment described an ECDSA root KSK generated in 2027. That work is separate from the 11 October signing switch.

The post-quantum note is Cloudflare’s aside, not an IANA date. Cloudflare writes that ECDSA is not a post-quantum algorithm, and that 1.1.1.1 now validates ML-DSA-44 signatures. A post-quantum chain would still need the signed domains, their parents, and the root. At the root, Cloudflare says, that is another KSK rollover.

11 October changes which key signs. Cloudflare says the rest runs into 2027: revoke KSK-2017, remove it from the root zone, and delete its private key, each as its own step. The May FAQ puts revocation in the first quarter of 2027 and deletion from the two key-management facilities in the second and third quarters. Its revocation line also says the key leaves the root zone in that first quarter. The FAQ cuts are coarser than Cloudflare’s, so this brief prints no single revocation day.

The FAQ says the root-zone partners can reverse the change if trouble is widespread. That back-out is a contingency, not another date on the calendar.

Publishers who do not run a validating resolver can leave the rollover alone. Operators who do should confirm tag 38696 before 11 October, and follow their vendor and ICANN if the tag is missing.