What changed
The DNS root was scheduled to switch its DNSKEY signing key on October 11, 2026, replacing KSK-2017 (key tag 20326) with KSK-2024 (key tag 38696). ICANN introduced KSK-2024 into the root DNSKEY set in January 2025 so RFC 5011-enabled validating resolvers could learn and trust it ahead of the switch. The new and old keys use the same RSA/SHA-256 algorithm; this is a key/trust-anchor rollover, not a cryptographic algorithm migration. A resolver still relying only on the old trust anchor can fail validation and return SERVFAIL for otherwise healthy domains when cached old signatures expire. Cloudflare and Akamai issued operator guidance ahead of the scheduled date; neither establishes widespread post-cutover outages.
Why it matters
Builders running recursive DNS resolvers for their VPS fleet, office, VPN, customer networks or embedded infrastructure may see apparently unrelated sites and APIs fail at once even though the origin services are healthy. Operators who restore old images, use read-only trust-anchor stores or have disabled automatic updates face higher risk. Typical website owners using mainstream DNS providers do not need to rotate their own zone keys or change registrar DS records; the action belongs with validating recursive resolvers.
A root trust-anchor change can break names across domains
DNSSEC validation chains from the root DNSKEY set to TLD and domain records. A validating resolver missing KSK-2024 may reject that starting point, making domains under unrelated TLDs fail simultaneously. The change does not require every website to replace its own DNSSEC keys or DS records.
RFC 5011 had nearly two years to distribute the new key
KSK-2024 has been published alongside the old key since January 11, 2025. RFC 5011 requires a hold-down period of at least 30 days before accepting a new trust anchor. Resolver upgrades, image restores, stale appliance configurations or unwritable trust-anchor files can defeat that automatic adoption even when software nominally supports it.
Check the resolver actually in use
Cloudflare provides a browser readiness test and describes RFC 8509 sentinel queries: a resolver supporting the protocol should return an answer for `is-ta-38696` and SERVFAIL for `not-ta-38696` when the new key is trusted. Unsupported sentinel behavior is inconclusive rather than proof of failure. Confirm the active resolver's loaded trust-anchor state, not just a package version or file on disk.
Most domain owners do not need to change anything
Cloudflare says 1.1.1.1, Gateway DNS and its authoritative DNS users already have the replacement trust anchor where relevant. Operators of their own BIND, Unbound, PowerDNS or other validating resolvers should follow vendor-specific trust-anchor instructions; do not blindly replace DNS zone keys or registrar DS records.
Outage claims need post-cutover evidence
The official schedule and pre-cutover technical guidance establish the risk and the required preparation. This dossier does not claim the rollover caused a measurable global outage. Monitor resolver validation errors, SERVFAIL spikes and ICANN/operator status reports during the 48-hour old-record-cache window.