Updated October 18, 2026. The planned rollover has happened: KSK-2024, key tag 38696, began signing the DNS root on October 11. IANA confirmed the new key entered service. IANA announcement.
On October 15, ICANN reported that the rollover was completed as planned. It is assessing reports affecting a limited number of systems and their potential relationship to the transition. This does not establish a widespread outage. ICANN update.
What changed, and what remains?
DNSSEC authenticates DNS data through a chain of signatures. The root KSK is the trust anchor at the top. A validating resolver must trust the appropriate key to verify answers.
| Milestone | Status |
|---|---|
| Advance publication of KSK-2024 | Completed to support resolver updates |
| KSK-2024 begins signing the root | October 11, 2026 |
| Previous KSK revocation | Scheduled for January 2027 |
IANA maintains the official schedule and trust anchors. Activating the new key does not complete every maintenance step.
Who should check their environment now?
Users of maintained ISP or public resolvers generally rely on the operator to manage the update. There is no reason to change passwords or DNS addresses simply because the key changed.
Operators of their own resolvers should verify key tag 38696 in the trust-anchor state actually used by the software. Prioritize older installations, manual anchors, unsupported appliances, and servers that were offline for extended periods.
RFC 5011 enables automatic trust-anchor updates, but operation depends on the resolver maintaining state and observing changes. Consult documentation for the installed version before reloading the service or editing files.
Investigating SERVFAIL after the rollover
We recommend starting with two queries to the same resolver, replacing DNS_ADDRESS:
dig @DNS_ADDRESS cloudflare.com A +dnssec
dig @DNS_ADDRESS dnssec-failed.org A +dnssecThe second domain deliberately has invalid DNSSEC. A SERVFAIL response there alone does not prove validation is working: a resolver with a broken anchor might fail every query.
Check that the first domain resolves, inspect the authentication indication (ad, where applicable), and check that the invalid domain is rejected. Then review validation logs, the server clock, and trust anchors. These queries do not replace configuration inspection, and an arbitrary SERVFAIL does not prove a rollover issue.
Benchmarking after the event
Compare current results with previous measurements if available. Without historical data, establish a baseline now using the same domains, network, and comparable times. Observe availability, failures, median latency, P95, and jitter where available.
Latency can support investigation but cannot identify a cryptographic failure alone. See DNS Benchmark for IT professionals for an operational workflow. Enterprise networks should use approved alternatives to preserve internal names and access policies.
Did this rollover make DNS post-quantum?
No. Replacing a key and migrating the signature algorithm are different processes. Read what post-quantum DNSSEC changes on 1.1.1.1.
