The DNS root zone switched to a new cryptographic key on October 11. At 14:00 UTC, the root key-signing key known as KSK-2024 began signing the root zone, replacing KSK-2017, which had held that job since October 2018. It is only the second root KSK rollover in the history of DNSSEC.
ICANN said in a status update on its rollover page that the switch happened as scheduled and that it had seen no indications of widespread operational disruption. IANA, which manages the root zone’s trust anchors, confirmed the change in a notice the same day.
What changed at the top of DNS
DNSSEC lets a resolver check that a DNS answer has not been forged by following a chain of signatures from the root down to the name it looked up. The root KSK sits at the top of that chain: it signs the root zone’s key set, and validating resolvers ship with a copy of it, called a trust anchor, as the fixed point they trust. Our guide to how DNS works covers the lookup path this chain protects.
According to IANA’s trust anchor page, the new key carries key tag 38696. The old one, KSK-2017 with key tag 20326, signed the root key set from October 11, 2018 to October 11, 2026. It stays in the zone for now and is still listed as a valid trust anchor.
The change was a long time coming. IANA lists these steps for the current rollover:
| Step | Date |
|---|---|
| KSK-2024 published in the root zone | January 11, 2025 |
| Resolvers using RFC 5011 begin to trust KSK-2024 | February 10, 2025 |
| KSK-2024 takes over signing | October 11, 2026 |
| KSK-2017 published with the revoke bit set | January 11, 2027 |
| KSK-2017 removed from the root zone | March 22, 2027 |
Both keys use the same algorithm, RSA/SHA-256, with 2048-bit keys. ICANN’s guide to what to expect during the rollover says the next rollover, expected to conclude around 2029, is planned to change the algorithm to ECDSA as well.
Who could be affected
Most people will notice nothing. Only resolvers that validate DNSSEC depend on the root trust anchor, and most of those were expected to pick up the new key automatically. In a July 27 post, ICANN said more than 95 percent of reporting resolvers had recognized and adopted KSK-2024.
The risk sits with the rest: validating resolvers whose trust anchor configuration still holds only KSK-2017. For those, ICANN warns of complete DNS resolution failures, which for their users look like the internet going down.
The failure does not necessarily appear at 14:00 UTC on rollover day. The root key set has a time-to-live of 48 hours, so a resolver that validated it shortly before the switch can keep using its cached copy for up to two days. ICANN says the exact moment an unprepared resolver starts failing is not predictable, and on a lightly used resolver it can come hours or days after the cache expires.
What resolver operators should check
ICANN’s advice is not to assume that automatic updates worked. Operators should look for key tag 38696 in their trust anchor file. ICANN names the usual locations:
- ISC BIND:
bind.keys - Unbound and PowerDNS Recursor:
root.key - Knot Resolver:
root.keys
If the key is missing, ICANN says to confirm that automatic trust anchor updates are enabled and that the resolver can write to its storage directory, then follow the vendor’s instructions. Software that does not use RFC 5011 can load the trust anchor file that IANA publishes.
For a resolver that is already failing, ICANN’s guide describes a temporary way out: switch DNSSEC validation off, or set a negative trust anchor for the root as defined in RFC 7646. That stops the failures at once, at the cost of losing validation. The operator should then install KSK-2024 and turn validation back on as soon as possible. Operators that do not validate DNSSEC are not affected and need do nothing.
ICANN asks anyone who sees problems that may be related to the rollover to email globalsupport@icann.org with “KSK Rollover” in the subject line. Major internet and cloud outages, with the providers’ own post-incident reports, are collected in our outages tracker.
