IANA confirmed that the DNS root zone began using a new Key Signing Key (KSK) on October 11. The KSK serves as the trust anchor, the starting point of DNSSEC validation.
According to ICANN, the rollover took place at 14:00 UTC, 23:00 Korea time. The new key is KSK-2024, identified by key tag 38696.
Most users were not expected to see disruption. Validating resolvers not updated to trust the new key, however, may fail DNSSEC validation.
What ICANN’s status report covers
ICANN’s status page reports that no indications of widespread operational disruption have been observed and that monitoring continues.
The same page asks operators of validating resolvers to confirm KSK-2024 (key tag 38696) is in their trust anchor configuration. It says not to assume automatic updates succeeded, and if the key is missing, to confirm automatic updates are enabled and follow vendor guidance.
An observation of no widespread disruption is a report of limited scope. It does not certify that every individual network is healthy.
Rolling the active signing key and removing the old anchor are separate steps
According to IANA’s trust anchor page, KSK-2024 was published in the root zone on January 11, 2025. Resolvers following RFC 5011 automatic updates were expected to trust it from February 10, 2025.
RFC 5011 is an automatic update mechanism that establishes trust in a new key after it has been observed in the root zone, signed by the current key, for a period.
KSK-2017 has not signed since October 11 but remains a valid trust anchor. Its revocation is scheduled for January 11, 2027 and removal from the root zone for March 22, 2027.
Deleting KSK-2017 early because of the October rollover is therefore not a step in IANA’s schedule.
A resolver inventory that includes recovery paths
An inventory check that stops at the busiest resolvers leaves gaps. Standby systems, rarely booted recovery environments and systems restored from old images belong in scope.
This is a recommended audit scope, not evidence that those systems failed. Even when production paths look healthy, recovery paths can stay on an old trust state.
Recording the resolver product, update procedure and observed anchor state leaves a basis for judgment. The key tag is an identifier for checking, not a secret credential to rotate in applications.
Evidence to compare during an incident
A suspected incident is compared against the resolvers that actually validated and the rollover time. A single failed lookup is weak grounds for calling it a key rollover failure.
Conversely, one working path through one resolver does not mean every validation path is ready.
Useful evidence is the state of each relevant resolver and the behavior of the services going through it. Preserving diagnostic observations before changing settings makes it possible to tell recovery from coincidence.
Caveats: disabling validation is not a repair
Turning off DNSSEC validation makes failures disappear, but it does not fix a missing trust relationship. Confirming the new anchor through a supported update procedure is the path that keeps the intended policy.
This article did not perform real resolver queries or network tests and does not conclude that any reader was affected.
The rollover is done; what remains is confirming that both the paths in use now and the paths relied on during recovery trust key tag 38696.