Summary

  • APNIC’s October report pairs a July RFC 8145 resolver-signal summary with renewed RFC 8509 tests of end systems. The roughly 90% and 70% figures describe different observation paths and cannot be subtracted or averaged.
  • The network table is a filtered watchlist for follow-up, not a grade for an ISP or an estimate of customers at risk. Operators still need to test their own validating resolvers against the scheduled change.

Analysis

A percentage needs its observation path

Two days before a scheduled change to the root DNSSEC key, a readiness percentage looks like the number everyone wants. If most resolvers have the successor key, the roll should be safe; if too many have not, someone should stop it. The problem begins with the word “most.” A resolver signal, a test run through an end user’s network and the people who use that network are not interchangeable units.

APNIC’s 9 October report, written on 8 October, offers a timely case study. It describes one result from RFC 8145, a way for validating resolvers to signal the key tags they trust in queries visible to authoritative-server operators. It then reports a separate test using RFC 8509’s Root Key Trust Anchor Sentinel. The first observation reaches outward from resolvers toward root servers. The second sends a probe through an end system and infers something about the resolver path from the response. Both concern the same root-key rollover. They do not count the same thing.

There is also a small but material wrinkle inside the RFC 8145 account. APNIC describes its July chart as showing that around 90% of reporting resolvers have added KSK-2024. Verisign’s 28 July update says adoption among signal-sending sources had passed 95% after roughly 500 days. APNIC attributes the chart to Verisign, yet the two public descriptions do not state a common extraction date and metric definition that lets a reader reconcile the figures. They may refer to different cuts or summaries of the signal; the available prose does not settle that. It is a documentation gap to preserve, not proof that either measurement failed.

The newer 70% figure is further away from a direct comparison. APNIC says its ad-based platform averaged about 16 million end-system tests a day. Roughly 6 million daily tests showed an end system behind a DNSSEC-validating recursive resolver, and around 1.8 million produced a clear signal that the resolver path supported RFC 8509. Within tests that appeared to support that sentinel, about 70% reported that KSK-2024 was loaded. The denominator is the tested subset with a clear signal, not all 16 million tests, all validating resolvers or all Internet users.

Two protocols, two questions

RFC 8145 lets a validating resolver tell a server which key tags it has in its chain of trust. It has two optional signaling methods: an EDNS option and a special query. For the root zone, those signals can be seen by operators of root authoritative infrastructure. The resulting data can show how reported key state changes over time among sources that send the signals.

That is useful, but it does not attach a resolver to the number of households, businesses or services behind it. Some recursive systems serve very large populations; others serve one organization or one machine. A forwarding chain can also affect what the root operator sees. A percentage of reporting signals therefore answers a question about those signals. It is not a user-weighted measure of exposure.

RFC 8509 takes a different route. A tester issues specially formed DNS queries; a supporting validating resolver returns behavior that indicates whether a named root key is trusted. APNIC uses an advertising-based measurement platform to send these tests through a collection of end systems. The useful observation is closer to the resolution path experienced by a tested endpoint, but it still depends on the path’s resolver support and the test’s ability to classify the response. It does not identify every resolver behind the endpoint, or count all users who share that resolver.

APNIC’s 5 October RIPE Atlas run adds a third view, not a universal cross-check. Probes in 2,900 distinct autonomous systems produced 1,230 behaviors consistent with the new key being loaded and 47 consistent with it not being loaded. These are probe outcomes in those networks. They do not mean that all 2,900 systems were measured completely, and they do not tell how many customers depend on any one result.

The lesson is not that the measurements are useless because they are partial. Each can locate a different operational question. RFC 8145 can show what signal-sending resolvers report toward the root. RFC 8509 can test the behavior of a participating resolver path behind an end system. A RIPE Atlas probe adds an independently situated vantage point. What none supplies alone is a complete, user-weighted denominator for the whole Internet.

A watchlist is a place to look

The most actionable part of APNIC’s report is not the global percentage. Its Table 3 lists 50 networks with the lowest observed KSK-2024 acceptance rates over the preceding week, after filtering for at least 1,000 tests that showed support for the sentinel mechanism. This condition makes the rows more interpretable than a list of every network seen once. It does not turn them into audited readiness grades.

The table includes Asia-Pacific networks, among them National Telecom in Thailand and Teletalk in Bangladesh. APNIC reports 48.4% for National Telecom across 1,355 sentinel-supporting tests and 48.2% for Teletalk across 2,046. These figures identify a cohort in which further checking may be worthwhile. They do not show that every resolver operated by either ISP has the same trust-anchor state, that the remaining test responses represent separate people, or that a corresponding share of customers will lose access.

APNIC suggests that listed networks test their own resolver path, including through a Cloudflare-operated checking page, and review their DNS settings. That is the right use of the table: as a lead for an operator, not as an external verdict. A provider may run multiple recursive services, forward some traffic, rely on vendor-maintained keys or serve customers whose devices use a different resolver. The public table cannot adjudicate those configurations.

The calendar has three distinct transitions

IANA’s current schedule says KSK-2024 entered the root zone on 11 January 2025, with the RFC 5011 trust period expected to begin a month later. On 11 October 2026, KSK-2024 is scheduled to sign the root zone and KSK-2017 is scheduled to stop signing. The old key is not scheduled for revocation until 11 January 2027, and removal is scheduled for 22 March.

Those dates describe different states. “The new key signs” does not mean “the old key is revoked,” and revocation does not mean that it has already been removed from the zone. RFC 5011’s add hold-down gives a resolver time to observe and validate a successor key before trusting it automatically. But the existence of an automatic protocol does not prove that a particular deployment enabled it, retained writable state or received the required observations.

The schedule also identifies who controls which part of the process. IANA publishes the root trust-anchor material and current dates; ICANN/PTI operates the root KSK process; Verisign’s role includes root-zone maintenance and a root-server observation point; APNIC reports measurements. A network operator remains responsible for the recursive resolvers on which its own users depend. APNIC can contribute evidence, but it does not control the root key or decide whether the global transition proceeds.

For an operator, the immediate check is local and specific: verify that the deployed resolver trusts the correct successor key, confirm that automatic updates or the approved manual path are actually functioning, and test the resolver paths used by production users. IANA publishes the trust-anchor files; resolver vendors publish their own instructions. A public measurement can suggest where to look. It cannot do that check on an organization’s behalf.

The evidence available on 9 October supports a bounded conclusion. The successor key has been published for more than a year, a large share of observed signals and test paths report it, and APNIC has identified networks where targeted follow-up may be useful. The 90%, above-95% and 70% descriptions do not resolve to one readiness score. On 11 October, the operational question will be whether a given validating path accepts the new signed root, not which of those percentages is the headline.

Sources

APNIC’s 9 October measurement report; IANA’s trust-anchor and rollover schedule; RFC 8145; RFC 8509; RFC 5011; Verisign’s 28 July update; ICANN’s 2026 operator FAQ; Cloudflare’s KSK-2024 resolver test.