Self-run DNSSEC resolvers have until October 11 to trust root key KSK-2024

The root is the one zone with no parent to vouch for it ^[7]. Below the root, each parent publishes a DS record holding a fingerprint of its child's key ^[7]. At the top, a validating resolver has to start from a root key it already holds, called a trust anchor ^[7]. The root KSK signs one thing, the root's DNSKEY set ^[8]. The resolver verifies that set against its anchor, then uses the zone-signing key inside it to check the rest of the root, including the DS record for every top-level domain ^[8].

That ordering decides where a stale anchor breaks. A resolver that trusts only KSK-2017, key tag 20326, cannot verify a DNSKEY set signed by KSK-2024 ^[20]. Validation fails at the root, before any top-level domain is checked ^[20]. Cloudflare's write-ups of the .de and .al failures showed how that looks to a user: sites working normally and still unreachable ^[16].

RFC 5011 is the automatic path ^[11]. The root lists the new KSK beside the old one, and the old one keeps signing, so the new key arrives under a signature the resolver already trusts ^[11]. The resolver then waits at least 30 days, keeps checking that the new key stays in the signed records, and verifies once more before accepting it ^[12]. Counted from the January 2025 publication, the root gave resolvers 638 days ^[18].

That runway belongs only to a resolver that kept its state the whole time. Each resolver's wait starts when it first sees and verifies the new key ^[14]. Subtract the 30-day minimum from October 11 and the last start date is September 11, 2026 ^[19]. A resolver whose clock starts after that cannot accept KSK-2024 through RFC 5011 before the switch ^[19].

Cloudflare's instruction for validating resolvers is to confirm KSK-2024 is trusted and, if it is missing, to update the trust anchors following the software vendor's instructions ^[4]. The identifier to look for is key tag 38696 ^[10]. Checking was the hard part last time. "Publishing the key well in advance was only part of the job," Cloudflare wrote of the 2018 rollover. "We also needed to know whether resolvers had retained it, and we couldn't give users a practical way to check." ^[17]

For its own resolver, Cloudflare added KSK-2024 directly to the software's built-in trust anchors in July ^[15]. I think that is the right choice for anyone running a resolver fleet. A built-in or configured anchor does not depend on state learned through RFC 5011, and learned state is what went missing in 2018 ^[22].