Summary

  • APNIC’s roughly 70% result is conditional on tests that clearly emitted the RFC 8509 sentinel signal; Verisign’s roughly 90% result concerns resolvers that reported under RFC 8145. They are not two estimates of one population.
  • The root began signing with KSK-2024 on 11 October 2026. The public evidence confirms the transition and no observed widespread disruption, but it does not count all resolvers, unique people or isolated failures.

A percentage needs its denominator

The most tempting reading of APNIC’s rollover figures is also the least defensible: if about 70% of the measured group trusted the incoming key, then perhaps the remaining 30% of users were exposed. That conclusion changes the denominator without evidence. APNIC Labs did not claim to have counted every resolver or person. Its result describes tests that displayed a particular measurement capability.

APNIC says its ad-based system generates about 16 million tests a day. Around six million daily results indicate a DNSSEC-validating resolver, and about 1.8 million provide a clear RFC 8509 sentinel signal. The roughly 70% figure is calculated within tests that appear to support that signal and report KSK-2024 as trusted. A test is an observation, not a proven unique user. Repeated events may come from the same people, network or resolver; the public methodology does not turn them into a population-weighted census.

This is still useful evidence. It shows that, among a measurable subset able to answer this test, the new trust anchor was not universal at the time APNIC collected the observations. It can help identify patterns and direct follow-up. Its value depends on keeping the condition attached to the number.

Verisign observed a different signal

The approximately 90% figure summarized by APNIC comes from Verisign’s RFC 8145 reporting. A resolver that supports the mechanism can send a signal about the key tags it recognizes as trust anchors toward the root-server system. This is a different observation point from an end-user-facing RFC 8509 sentinel query. The set includes resolvers that both support the reporting mechanism and produce observable reports; it does not include every recursive resolver by definition.

Nor is one reporting resolver one person. A resolver may serve a household, an enterprise, an access provider or many downstream networks. The available report does not supply a user count per resolver that would allow the observations to be weighted by people. Differences between 70% and 90% therefore do not establish a contradiction, a trend between equivalent samples or a ten-point change in global readiness. The protocols, eligibility conditions, collection windows and paths through the network differ.

A small RIPE Atlas exercise provides a third kind of check, not a referee for the two percentages. On 5 October, probes across 2,900 autonomous systems included 1,230 whose behavior was consistent with the new key being loaded and 47 consistent with it not being loaded. The probe set was limited and not weighted by users. APNIC’s table of networks with low acceptance rates also uses a minimum number of supporting tests to make the observations more interpretable; that threshold does not convert a sampled network into proof of a network-wide outage.

Root signing is not local trust state

IANA lists KSK-2024, key tag 38696, as active and signing the root zone since 11 October. KSK-2017, tag 20326, remains in the post-publication phase and is still a valid trust anchor. Its scheduled revocation is 11 January 2027, with removal planned for 22 March. These are separate operational states: the incoming key can sign while a validator still retains the outgoing key as valid.

ICANN’s rollover status says the new key began signing at 14:00 UTC on 11 October and reports no indications of widespread operational disruption observed in its update, with monitoring continuing. That is evidence about the observed operational picture, not proof that every local validator had accepted the key. It also does not establish that no isolated failure occurred. Conversely, a test that does not show the new key is not by itself evidence that a user’s DNS lookup failed.

The failure mechanism is conditional. A resolver that performs DNSSEC validation and lacks a usable trust path for the root can reject signed data. A resolver that does not validate DNSSEC does not fail through this specific path. Even for a validating resolver, the actual outcome depends on its local trust-anchor state, configuration and query path. The root’s signature answers what key signed the zone; it does not reveal the state of every validator downstream.

What the measurements can support

The evidence supports three bounded conclusions. First, the rollover occurred as scheduled. Second, multiple instruments found substantial adoption, but each instrument describes its own observable subset. Third, the public post-roll statement reviewed here did not indicate widespread disruption. It does not support the claim that 30% of users were at risk, that 10% of all resolvers missed the key, or that readiness reached 100%.

The missing quantity is not another headline percentage. It is a defensible mapping from observations to the number and distribution of affected validating resolvers, then from those resolvers to the users and services behind them. That would require explicit coverage, deduplication, time windows, weighting and a post-roll outcome measure. Until those are available, report the denominator with every rate and keep observed key state separate from inferred user impact.

Sources