Skip to content

CLOUDFLARE 2026-10-06 Tier 1

Read original ↗

The keys to the Internet change on October 11, 2026. Are you ready?

Summary

On October 11, 2026 the DNS root zone changes its key-signing key (KSK) for only the second time ever — a KSK rollover that swaps KSK-2017 (key tag 20326) for KSK-2024 (key tag 38696) as the signer of the root's DNSKEY RRset. The KSK anchors DNSSEC's chain of trust, so a validating resolver that does not trust the replacement key before the switch can fail to validate answers under any TLD — healthy websites become unreachable even though nothing is wrong with them. This Cloudflare post (2026-10-06) explains how resolvers learn the new trust anchor (RFC 5011 automatic updates, or built-in anchors shipped in resolver software), and introduces an RFC 8509 root-key sentinel readiness test (dnstest.dev/ksk-2024) that lets a user ask their resolver "do you trust key 38696?" with ordinary DNS queries. systems/cloudflare-1-1-1-1-resolver|1.1.1.1 / Gateway DNS already trust KSK-2024 (added to Big Pineapple's built-in anchors in July 2024), and 1.1.1.1 implements the sentinel. The post frames the rollover as a rehearsal for the harder migrations to come — an algorithm rollover (RSA → ECDSA P-256) and eventually a post-quantum KSK.

Key takeaways

  1. The KSK is the root of DNSSEC's chain of trust. The root's two keys split duties: the zone-signing key (ZSK) signs the root's DNS records (including the DS records for TLDs like .com); the key-signing key (KSK) signs the root's DNSKEY RRset (the published key list). A resolver starts from a trust anchor (the KSK, or its fingerprint) it already trusts, uses it to verify the DNSKEY set, then uses the ZSK from that set to verify everything else. The root is special because it has no parent DS record — trust must be preconfigured, not delegated. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
  2. The blast radius of a failed root-KSK rollover is total. DNSSEC validation fails closed — a working website whose validation path breaks is unreachable, not degraded. The .de (2026-05) and .al (2026-07) TLD rollover failures showed this at TLD scope; a root KSK the resolver doesn't trust breaks validation under every TLD at once. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
  3. KSK-2024 (tag 38696) replaces KSK-2017 (tag 20326). Both use RSA/SHA-256 — this is a key rollover, not an algorithm rollover; the signing method is unchanged. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
  4. RFC 5011 is how resolvers learn the new anchor automatically. The root publishes the new KSK alongside the existing one in the DNSKEY set, still signed by the currently-trusted KSK, so a resolver can verify the newcomer with the key it already has. Before accepting it, the resolver waits ≥ 30 days while continuously re-checking that the new key stays present and verifiable, then must successfully verify it again. KSK-2024 has been published in the root DNSKEY set since January 11, 2025, giving auto-updating resolvers ~21 months to discover and accept it before the October 11, 2026 signing change. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
  5. Cloudflare chose built-in anchors over learned state. Rather than rely on each resolver retaining an RFC-5011-learned key across upgrades and machine moves (which caused lost trust during the 2017 rollover), Cloudflare added KSK-2024 directly to the resolver software's built-in trust anchors in July 2024 — so a resolver running the updated binary has the anchor from startup. This echoes the fix from the 2018 "destroying HSMs" post. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
  6. RFC 8509 root-key sentinel: ask the resolver what it trusts. Two specially-named labels pose opposite questions about a key tag: root-key-sentinel-is-ta-38696 ("is this a trust anchor?") and root-key-sentinel-not-ta-38696 ("is this not a trust anchor?"). Both names have valid DNSSEC-signed A records; a sentinel-supporting validating resolver first validates them, then either returns the answer or substitutes SERVFAIL depending on whether it trusts the key. When KSK-2024 is trusted: is-ta-38696 → valid answer, not-ta-38696 → SERVFAIL. 1.1.1.1 implements RFC 8509; test directly with dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev A. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
  7. The readiness test is designed to avoid false negatives. dnstest.dev/ksk-2024 also checks that an ordinary signed name resolves, that a deliberately-invalid DNSSEC name is rejected, and that the resolver answers a sentinel query for the current root key — these controls distinguish a real result from "sentinel unsupported." If sentinel support can't be established the result is inconclusive, which explicitly does not mean the new key is missing. The browser test measures whatever resolver the browser uses (which Secure DNS or a VPN can change); the dig commands pin to 1.1.1.1. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
  8. Most operators need to do nothing — the exception is self-run validating resolvers. If you use Cloudflare DNS, 1.1.1.1, or Gateway DNS, no action is needed. If you run a DNSSEC-validating resolver, confirm it trusts KSK-2024 (tag 38696) and follow your vendor's trust-anchor update instructions if the key is missing. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
  9. The rollover is a rehearsal for harder migrations. Regular key rollovers limit how long one private key is in use and exercise the trust-anchor distribution process — which can fail even when the cryptography works. The same muscle will be needed for an algorithm rollover (ICANN has proposed RSA → ECDSA P-256, which yields smaller keys/signatures but is not post-quantum) and ultimately a post-quantum KSK. 1.1.1.1 already validates ML-DSA-44 DNSSEC signatures; a PQ-secure chain of trust needs the root, parents, and signed zones all to adopt PQ, which means another root KSK rollover. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)

Operational numbers & facts

  • KSK-2024 — key tag 38696, published in root DNSKEY set since 2025-01-11; added to Cloudflare resolver built-in anchors July 2024.
  • KSK-2017 — key tag 20326; being replaced as DNSKEY signer 2026-10-11; ICANN plans to revoke it in 2027, remove it from the root zone, and delete its private key.
  • Both KSKs use RSA/SHA-256 (same algorithm; key-only rollover).
  • RFC 5011 hold-down: resolver waits ≥ 30 days of continuous presence + verification before accepting a new auto-learned anchor.
  • IANA's idealized rollover interval: three years (actual gap 2017→2024 was longer; ICANN attributes the delay to pandemic disruption + HSM upgrades).
  • The first root KSK rollover was in 2017/2018; this is the second.
  • Readiness test: https://dnstest.dev/ksk-2024/ (RFC 8509 sentinel over dnstest.dev).

Systems / concepts extracted

Caveats

  • A sentinel-based readiness test can only report inconclusive when sentinel support can't be established; inconclusive ≠ "new key missing." Operators of self-run resolvers should verify trust-anchor state directly, not infer it from a failed sentinel query.
  • The algorithm rollover (ECDSA P-256) and post-quantum KSK are separate, future events — this October's change keeps RSA. ECDSA is not a post-quantum algorithm.
  • DNSSEC provides authenticity, not confidentiality, so it is not subject to harvest-now-decrypt-later; the PQ threat to it is live forgery at Q-Day.

Source

Last updated · 854 distilled / 2,448 read