Resolvers that still trust only KSK-2017 on October 11 will either SERVFAIL or stop validating

A validating resolver holds one thing locally that it trusts without proof: a trust anchor, the public key it believes the root uses ^[5]. Every answer below the root validates up a chain that ends at that key ^[5]. IANA's rollover page describes the October 11 change in one line: "the successor key is scheduled to sign the zone; the current key will not." ^[2] Once that happens, a resolver whose anchors hold only KSK-2017 has no path up the chain ^[9]. The root zone becomes unvalidatable, and so does everything beneath it ^[9].

The rollover itself is careful work. KSK-2024 went into the root DNSKEY set beside KSK-2017 on January 11, 2025, and nothing changed while both keys sat there ^[3]. Validators got 21 months of overlap before the signing switch ^[20].

Uptime is where it breaks. RFC 5011 promotes a new key only after a 30-day hold-down with regular queries ^[4]. It assumes the resolver kept running and querying through the transition ^[6]. The post names the boxes that did not: validators left switched off for a month, appliances working from cached anchors, and VM snapshots brought back up once the hold-down window had already passed ^[7]. Five days before the switch, the remaining window is 25 days shorter than the hold-down ^[19]. A resolver that has not already promoted KSK-2024 will not get there automatically in time ^[19]. The author's advice is to update the trust anchor by hand ^[8].

What happens next depends on configuration ^[11]. The post opens by saying "everything looks normal, and names stop resolving" ^[10]. Its own breakdown separates those two outcomes. Strict validation returns SERVFAIL, which the author called "Annoying, visible, fixable in minutes once you know why." ^[11] Opportunistic validation falls back to unvalidated answers with no error or log line ^[12]. Names keep resolving while DNSSEC protection stops ^[12]. In my view strict is the right setting for anyone running their own validator, because its failure shows up on the first lookup ^[11].

The post gives three checks ^[13]:

1. `dig . DNSKEY +dnssec +multiline | grep "key tag"` should show both 20326 (KSK-2017) and 38696 (KSK-2024) in the root DNSKEY set today ^[13]. 2. `delv @YOUR_RESOLVER dev.to` should report a fully validated answer. Without delv, an `ad` flag in `dig +dnssec @YOUR_RESOLVER dev.to` means the resolver validated ^[14]. 3. `unbound-anchor -l` on Unbound, or `rndc managed-keys status` on BIND9, must list KSK-2024 as trusted before October 11 ^[15].

The second check says whether validation works now, and the third says whether it will on October 12 ^[16]. After the switch, the `ad` flag is also how to tell an opportunistic resolver that stopped validating from one that still validates ^[12][14].

According to the author, the big public resolvers have served the new key for months ^[21]. The exposure sits with self-hosted Unbound, BIND, Knot and PowerDNS, office DNS appliances, embedded boxes on firmware not updated since 2024, and paused homelab VMs ^[21]. The author also counted the dev.to posts about the rollover on the day of writing and found zero ^[22].

The first root KSK rollover, in 2017, was postponed because measurement showed most validating resolvers were not ready ^[17]. KSK-2017 has authenticated the root since October 11, 2018 ^[1].