The DNS root has a new signing key. The transition is not over
KSK-2024 is active after the October 11 switch. Operators still need to verify trust anchors, and retirement of the previous key continues into 2027.
The DNS root has changed a key used to authenticate internet address information. ICANN says the scheduled October 11 rollover completed as planned, while its October 15 update acknowledges reports affecting a limited number of systems and says their relationship to the transition is still being assessed. That is a measured operational report, not evidence that the internet's naming system broadly failed.
Most readers will have noticed nothing. That is the intended experience of maintenance beneath everyday browsing: resolvers continue checking signed information while the cryptographic material at the top of the trust chain changes.
What the root key actually protects
The Domain Name System connects names to information computers need to find services. DNS Security Extensions, or DNSSEC, add a way to authenticate DNS data. The root key signing key anchors that validation chain; it is not a password for websites, and replacing it does not mean every site's encryption key has changed.
In its October 15 report, ICANN explains that periodic replacement also exercises the procedures, software and coordination needed to manage the key. A successful rotation demonstrates something that merely retaining a trusted key cannot: participating systems can accept its successor.
Think of a directory whose entries arrive with verifiable seals. A verifier needs an accepted starting point for deciding which seals to trust. Changing that starting material safely requires agreement between the publisher and the systems performing verification. The directory can remain reachable even when a particular verifier has failed to learn the replacement, so availability alone does not establish that validation is healthy.
The transition started long before October
IANA's trust-anchor schedule shows that KSK-2024 was introduced into the root zone in January 2025. The long overlap gave resolvers time to establish trust before it became the active signing key. IANA describes both automatic trust-anchor updates and updates distributed through software vendors.
The remaining dates explain why the operation does not end with one successful switch. Systems need to recognize the replacement and eventually retire the old trust anchor. Keeping a transition understandable over that whole period is part of operating a shared infrastructure whose participants update at different times.
ICANN's current guidance asks operators of validating resolvers to check that KSK-2024, identified by key tag 38696, is present. It explicitly warns against assuming automatic updates succeeded. Missing-key remediation should follow the resolver vendor's instructions. This is work for the operator of the validating service; ordinary readers do not need to install a mysterious new browser key.
Rotation is different from changing the algorithm
There is a second cryptographic project to keep separate. ICANN's root KSK algorithm-rollover consultation concerns a proposed move from RSA to ECDSA, with its own staged timetable. Replacing a key and replacing the mathematical algorithm behind keys are different changes with different compatibility implications.
Neither should be casually described as the DNS becoming quantum-proof. Our earlier explanation of NIST's post-quantum standards addresses that separate class of cryptography. Grouping all three under “new encryption” would conceal what each project is trying to accomplish.
The useful result this week is narrower and more tangible: the new root signing key is active, broad disruption has not been observed, and the retirement sequence remains underway. For resolver operators, the remaining responsibility is to verify the state of their own systems. A quiet transition is valuable precisely because trust maintenance has happened without demanding the attention of every person opening a website.
