On 11 October the DNS root changes its key for only the second time ever, and if you run your own resolver, you check that it trusts the new one

On Monday we entered a DS record for our site and DNSSEC went live here. On Sunday the key under the whole chain above us changes.

The root has no parent to vouch for it. So the resolver, the program that looks up a site's address for your device, starts its check from a key it trusts in advance, and that very key is being replaced.

The cost of a miss is clear. If a resolver does not trust the new key, its users may be unable to reach websites under any top-level domain, Cloudflare writes, even though the sites work normally.

The fault will not be in the site. It will be in the resolver that did not trust the new key in time.

Most people do nothing. If you just run a website or use someone else's resolver, this is not about you. That leaves those who run their own resolver with DNSSEC validation. The new key has sat in the root since January 2025, and a resolver waits at least 30 days before it trusts it. ICANN still wants you not to assume that worked.

The readiness test is at dnstest.dev/ksk-2024. It asks the resolver your browser uses whether it trusts KSK-2024. An inconclusive result does not mean the key is missing: it means the test could not establish whether the resolver supports the check. Secure DNS or a VPN in the browser can also change which resolver you are checking.

The old key does not vanish on Sunday. Under ICANN's plan it is revoked and removed from the root in the first quarter of 2027, and deleted from the two key management facilities in the second and third quarters.

Run a resolver with DNSSEC? Check it before Sunday, 11 October. After that, other people will feel the mistake.

The visual is generated code-art, no third-party images.