Blog

On Sunday, October 11, 2026, the key at the very top of the DNS changes. The root zone will start signing its key set with a new Key Signing Key, KSK-2024 (key tag 38696), and stop using the key it has relied on since 2018. It’s only the second time the root key has ever been replaced.

For most people, nothing will happen. But any DNSSEC-validating resolver that doesn’t trust the new key will stop resolving everything (every website, mail server and API) within about two days. Here’s who needs to check, how to check in a few minutes, and what to do if something breaks. The short version for our customers: if your domains are hosted with CloudFloorDNS, there is nothing to change on your zones.

What actually changes on October 11

DNSSEC is a chain of signatures. Your domain’s keys are vouched for by its TLD (.com, .org, .us and so on), the TLD’s keys are vouched for by the root, and the root’s own keys are signed by one key at the top: the root Key Signing Key, or KSK. Every validating resolver carries a copy of that key, called a trust anchor, and checks every signed answer back to it.

Replace the key at the top and every validating resolver on the internet needs the new one. That’s why ICANN published KSK-2024 in the root zone on January 11, 2025, nearly two years ahead of time. Resolvers that update their trust anchors automatically (the RFC 5011 process) have been able to learn it since February 2025.

If you ever need to add the new key by hand, this is its DS record. Check it against IANA’s published trust anchors before relying on it. Trust anchors shouldn’t come from a blog post, including this one.

. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

The timeline

Who needs to do something

Only software that validates DNSSEC answers uses the root key. In practice that mostly means recursive resolvers: the servers that look up names on behalf of your computers and phones. Authoritative DNS, where your zones live, never touches the root trust anchor.

How to check a resolver in about five minutes

dig @192.0.2.53 dnssec-failed.org A

dig @192.0.2.53 root-key-sentinel-is-ta-38696.dnstest.dev A
dig @192.0.2.53 root-key-sentinel-not-ta-38696.dnstest.dev A

rndc managed-keys status
# look for "keyid: 38696" followed by "trusted since"

grep 38696 /var/lib/unbound/root.key
# look for "id = 38696" and ";;state=2 [  VALID  ]"
# the path varies by OS: it's auto-trust-anchor-file in unbound.conf

rec_control get-tas
# look for a line containing 38696

Get-DnsServerTrustAnchor -Name .
# look for key tag 38696 with state Valid
# no root trust anchors at all means this server isn't validating

grep -r "trust-anchor" /etc/dnsmasq.conf /etc/dnsmasq.d /etc/pihole 2>/dev/null
# you need a line containing 38696

dig @192.0.2.53 example.com A        # SERVFAIL?
dig @192.0.2.53 example.com A +cd    # works with checking disabled?

If something breaks

ICANN’s advice is the same for every resolver: restore service first, then fix the key. Temporarily turn off DNSSEC validation, or add a negative trust anchor for the root (RFC 7646), and lookups work again right away. Then install KSK-2024 and turn validation back on. Don’t leave it off.

Unbound: fetch the current root anchor from IANA, then restart

sudo -u unbound unbound-anchor -a /var/lib/unbound/root.key
sudo systemctl restart unbound

Windows Server DNS: pull the current root trust anchors from IANA

Add-DnsServerTrustAnchor -Root

PowerDNS Recursor: add it at runtime, then make it permanent in your configuration or upgrade to 5.2.0 or later

rec_control add-ta . 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

dnsmasq and Pi-hole: add this line to the dnsmasq configuration, then restart

trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

BIND: upgrade to a current release, whose built-in bind.keys includes KSK-2024, and use dnssec-validation auto;.

A reminder from May: what a DNSSEC failure looks like

On May 5, 2026, Germany’s .de registry hit a bug during a routine key rollover. DENIC’s signing software generated a separate key pair for each of its three hardware security modules instead of one shared pair, all with the same key tag, so only about a third of the zone’s signatures could be verified. For roughly three hours, people behind validating resolvers increasingly couldn’t reach .de sites, from amazon.de to bahn.de.

Three details from DENIC’s final report and Cloudflare’s write-up are worth knowing before October 11:

• It wasn’t only signed domains. The broken signatures included the records that prove a .de domain isn’t signed, so unsigned .de domains failed too.
• It got worse gradually. Cached answers kept things working at first, and failures climbed as TTLs expired. A missed root key will play out the same way over its 48-hour window.
• The alarms fired, but nobody acted on them. DENIC’s validation tools spotted the errors, but the notifications weren’t processed in time. Monitoring only helps if the alert reaches a person. Our monitoring guide covers how to set that up.

Cloudflare restored .de on 1.1.1.1 by temporarily treating the zone as unsigned, the same “negative trust anchor” lever ICANN suggests as a stopgap for the root.

What this means if you’re a CloudFloorDNS customer

Thinking about signing your own zones? DNSSEC is included with our Gold, Platinum and Custom Managed DNS plans.

What comes after October 11

• Early 2027: KSK-2017 is revoked, then removed from the root zone. Resolvers that update automatically handle this on their own.
• Certificates now depend on DNSSEC. Since March 15, 2026, public certificate authorities must validate DNSSEC when they check your CAA and domain-validation records (CA/Browser Forum ballot SC-085v2). If your zone is signed and a signature breaks, certificate renewals stop.
• A new algorithm for the root. ICANN has proposed moving the root KSK from RSA to ECDSA P-256, with the work running from 2027 to 2030.
• Post-quantum DNSSEC is being tested. On September 10, 2026, Cloudflare’s 1.1.1.1 began validating ML-DSA-44 signatures, which are about 38 times larger than today’s ECDSA signatures.

None of this is a reason to avoid DNSSEC. It’s a reason to run it with people who watch it closely.

Quick answers

Will my website or email stop working on October 11?

Almost certainly not. Your zones don’t change. The only people affected are users behind a validating resolver that missed the new key, and for them everything fails, not just your site. The big public resolvers have had nearly two years to prepare.

Do I need to change my DS records or DNSSEC keys?

No. The rollover changes only the key at the very top of the chain. The DS record at your registrar and your zone’s own keys stay exactly as they are.

How many resolvers aren’t ready?

Nobody knows precisely. ICANN reports that more than 95% of the resolvers that report their trust anchors have adopted KSK-2024. APNIC’s Geoff Huston measured far lower numbers using a different method, and puts the gap down to measurement uncertainty. About 35% of the world’s internet users sit behind validating resolvers, so even a small miss reaches a lot of people. Check your own rather than assume.

Why change the root key at all?

Cryptographic keys shouldn’t live forever, and the only way to keep a rollover process reliable is to use it. The first root rollover was in 2018. This is the second, and ICANN is already planning the next change.