Root KSK rollover on Oct 11: what web teams must check

On October 11, 2026 the DNS root is scheduled to change its key-signing key, an operation called a root KSK rollover. According to the Cloudflare Blog, this is only the second time the root KSK will be changed, and validating DNS resolvers need to trust the new key, KSK-2024, before that switch to avoid making otherwise healthy websites unreachable.

Root KSK rollover: what changed and why it matters

Cloudflare explains the role of the root KSK in DNSSEC: resolvers start DNSSEC validation from a trusted root public key, called a trust anchor, and the KSK signs the DNSKEY set that contains the root’s other signing key. For this rollover, KSK-2024 (key tag 38696) will replace KSK-2017 (key tag 20326) as the signer of the root’s DNSKEY set. Both keys use the same algorithm, RSA/SHA-256, so the rollover swaps the key material while keeping the verification method the same.

If a validating resolver does not have the new trust anchor before the root stops using the old KSK, DNSSEC validation can fail and resolvers may return errors instead of delivering otherwise working sites. Cloudflare notes past rollovers, including failures that affected .de and .al, where resolvers lost learned trust in the replacement and caused reachability problems.

How resolvers are supposed to get the new root key

Cloudflare describes two ways resolvers can obtain the new trust anchor. RFC 5011 lets resolvers learn a new root trust anchor automatically, by observing the new KSK published in the root’s DNSKEY set and waiting at least 30 days while rechecking signatures before accepting it. Cloudflare says KSK-2024 has been published in the root’s DNSKEY set since January 11, 2025, giving resolvers time to discover it automatically.

Based on lessons from the 2018 rollover, Cloudflare also added KSK-2024 directly to its resolver software’s built-in trust anchors in July 2024. That means a resolver running Cloudflare’s updated software will start with the new anchor already trusted. Cloudflare also states that if you use its domain DNS or rely on 1.1.1.1 and Gateway DNS, you do not need to take any action because those systems already trust KSK-2024.

How to check whether your resolver trusts KSK-2024

Cloudflare implemented RFC 8509, the root key trust anchor sentinel, so you can ask a supporting resolver whether it trusts a particular root key. Their readiness test uses two sentinel names that ask the opposite questions: is-ta-38696 asks whether KSK-2024 is trusted, and not-ta-38696 asks whether it is not trusted. Both names are DNSSEC-signed.

A resolver that supports the sentinel validates the records and then either returns the answer or deliberately returns SERVFAIL, depending on whether it trusts the key. For example, a validating resolver that trusts KSK-2024 will return a normal response for is-ta-38696 and SERVFAIL for not-ta-38696. Cloudflare shows dig queries against 1.1.1.1 using those sentinel names to demonstrate the behavior.

Cloudflare also notes the test checks several controls: that a normal 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. 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 can be affected by Secure DNS or a VPN. The dig commands query 1.1.1.1 directly.

Practical steps for web teams

• If you run a DNSSEC-validating resolver, check whether it trusts KSK-2024, KSK-2024 is identified by key tag 38696, and follow your software vendor’s instructions to update trust anchors if the key is missing, the Cloudflare Blog advises.
• If you rely on Cloudflare’s DNS for your domain or use 1.1.1.1 and Gateway DNS, Cloudflare says no action is required because their resolvers already trust KSK-2024.
• Use Cloudflare’s rollover readiness test or run the RFC 8509 sentinel queries (is-ta-38696 and not-ta-38696) against your resolver to confirm behavior; remember a SERVFAIL response on the opposite sentinel is the expected sign of trust.
• If you are unsure how your resolver obtains trust anchors, consult your resolver software vendor documentation about RFC 5011 and built-in trust anchors and follow their update instructions.

If you want help checking resolver settings or updating trust anchors for WordPress or Formidable Forms systems, we can assist, Running WordPress or Formidable Forms? Get help from a Formidable Masterminds developer.

What to watch after the rollover

Cloudflare notes replacing the key is useful even without an algorithm change: it limits the lifetime of a single private key and keeps the distribution process exercised. The Internet Assigned Numbers Authority has described a three-year idealized interval between rollovers, though the gap since the 2018 rollover has been longer. Because past rollovers showed that software upgrades, moves between machines, or missing built-in anchors can break learned trust, teams running their own validating resolvers should verify the new anchor is in place before October 11, 2026.

For most small business and nonprofit web teams that rely on managed resolvers, the main action is to confirm with your DNS provider or resolver vendor whether their systems already trust KSK-2024. For self-managed resolvers, run the sentinel checks and apply vendor guidance to add or update trust anchors if needed.

According to the Cloudflare Blog, taking these checks now avoids the risk that DNSSEC validation will block access to otherwise healthy sites when the root switches its KSK on October 11, 2026.