Resolvers anchored only on KSK-2017 should return SERVFAIL now that the root signs with KSK-2024

The dev.to post that lays out the failure puts the cause in one line: "A validating resolver does not discover trust; it is configured with it." ^[15] The root's DNSKEY RRset now arrives signed by KSK-2024, and a resolver whose only anchor is KSK-2017 was never told to trust that signer. With no way to build the chain, it marks the answer bogus and sends back SERVFAIL ^[11]. The signing algorithm is unchanged, so trust-anchor state is the only cause ^[12].

Most resolvers needed no operator. Against RFC 5011's 30-day hold, KSK-2024 had about 21 months of publication before the switch ^[18]. A resolver that ran continuously, with state it could write and persist, has trusted the key since early 2025 ^[5].

Two of the five non-updating cases fail in ways that are easy to miss. A resolver that was switched off, or restored from a snapshot, without completing its adoption of KSK-2024 is now stuck: it cannot validate the very RRset that would teach it the key ^[13]. A container may support RFC 5011 and still throw away its managed state when it restarts, which puts it back on the anchor its image shipped with after every restart ^[14].

Timing is what misleads operators. Because a resolver caches both the DNSKEY RRset and its signature, answers it validated under the old signature keep working until that cache expires ^[8]. Each resolver hits the symptom at its own moment. The root's response tells you how long the window lasts: it is set by the DNSKEY RRset's TTL and by how long its RRSIG stays valid ^[9].

The two adoption figures do not combine. Verisign's July data covers reporting resolvers, and APNIC's October measurement counts RFC 8509-capable test results ^[20][21]. The post says they are different populations measured different ways ^[22]. The 20-point gap between them ^[19] is not evidence of a decline since July. For either number to transfer, an estate's resolvers would have to look like the population that was measured, and the post says neither figure describes your resolvers ^[22].

The post is a single source and an operational one. Its author did not query IANA directly and relies on IANA's statement of the event ^[2]. The author also says the post reports no outage; it describes what a validating resolver without KSK-2024 is expected to do ^[16]. The proposed method is a worksheet holding three kinds of evidence per resolver ^[17], and the available text does not list them.

In our view the worksheet reduces to two questions per resolver. Is it one of the five categories that cannot update itself ^[6]? If it can update itself, does it keep its state across restarts ^[14]?