Summary

  • APNIC Labs observed 9,685,775,212 authoritative queries in 116,050,253 no-response tests. The published totals yield 83.46 queries per unique test, compared with 3.43 for a positive control, 3.93 for NODATA, 4.40 for NXDOMAIN, 11.47 for REFUSED and 51.73 for SERVFAIL.
  • Those ratios establish an association between the response condition and query load in the experiment. They do not identify whether repeats came from an endpoint, its stub, a forwarding service, a recursive engine, a resolver farm or several layers acting together.
  • The source prose and summary table disagree on two averages. Recomputing from the published counts resolves the arithmetic, but not authorial intent. Any operational use needs a receipt that preserves the denominator, formula, topology, transport, security state and unknown attribution.

A count can be exact while its actor remains unknown

The largest number in APNIC Labs’ 4 September report is 9,685,775,212. That is how many queries its authoritative server observed when the experiment returned no response. The denominator in the report’s summary table is 116,050,253 tests. Divide one by the other and the result is 83.4619 queries per unique test.

The arithmetic is simple. The path that produced it is not.

A script in an online advertisement caused an endpoint to resolve a randomly constructed name. The endpoint’s resolver library could ask one of several configured recursive services. A forwarding layer could sit between them. A large service could distribute the request across front ends and resolver engines. An engine could try more than one address or transport. Each of those components can generate work, join equivalent work, retry it or pass it onward. APNIC’s authoritative log sees the queries that reach the last measured boundary. It does not see a signed custody chain identifying every decision upstream.

Calling the result “83 queries from a resolver” would therefore add a fact the experiment does not contain. Even “83 retries” is too loose. A modern endpoint can legitimately ask for A, AAAA and HTTPS data. Those are different query types, not three retries of one packet. APNIC subtracts an expected base to discuss repetition, but the published unit remains a unique test name, not one human action, one application request, one stub transaction or one recursive transaction.

The distinction does not weaken the finding. It locates it. APNIC has measured what arrived at an authoritative service under six answer conditions. That is a valuable load ledger. It is not yet a ledger of who decided to send each query.

Six answer states produced six very different loads

The 2026 experiment used random names so a prior cached answer for the exact name could not satisfy the request. The zone was unsigned. One dual-stack authoritative nameserver accepted UDP and TCP, but not DoT or DoH. Responses were short and did not need truncation. Queries arriving within 24 hours of each advertisement placement were counted.

The published totals produce this comparison:

Authoritative condition Tests Queries observed Recomputed queries per test Multiple of positive control
Positive A/AAAA control 254,894,985 875,316,423 3.43 1.00×
NOERROR/NODATA 115,571,398 454,213,932 3.93 1.14×
NXDOMAIN 115,750,503 509,410,787 4.40 1.28×
REFUSED 115,415,259 1,324,355,211 11.47 3.34×
SERVFAIL 138,643,924 7,171,673,166 51.73 15.06×
No response 116,050,253 9,685,775,212 83.46 24.30×

The pattern is stronger than a comparison between “yes” and “no”. Positive answers and the two definitive negative forms remain near four queries per test. REFUSED is markedly higher. SERVFAIL and silence move into another range.

That ordering is consistent with meaning. NXDOMAIN says the name does not exist. NODATA says the name exists but the requested type does not. REFUSED says the server declines the operation, often for policy. SERVFAIL says the query could not be processed because of a problem and leaves open whether another server, address, transport or later attempt might fare differently. Silence says nothing at all; timers must decide what the missing response means.

Consistency is not identification. The table does not show which implementation read an RCODE, which front end retransmitted, how many equivalent requests were joined, or whether a failure caused a switch between server addresses. It also does not report a per-product distribution or the long tail hidden by each average. The result supports a response-state/load association within the test. It does not support assigning 51.73 queries to a universal SERVFAIL rule.

The expected base is already more than one

For the NXDOMAIN condition, APNIC reports that 48% of endpoints generated both A and AAAA queries, 51% generated only A, and 1% only AAAA. It also saw HTTPS queries from 39% of endpoints. On that mix, APNIC estimated 218 million queries if every used type were asked exactly once.

It observed 509,410,787. The remaining 291,919,927 were classified as repeats. Of the 115,750,503 tests, 67,316,541 completed with no more than one query for each type used. The other 48,433,962 tests carried the repeat total, yielding 6.03 repeat queries per repeat-bearing test.

This denominator work matters. A headline that compares 509 million packets with 116 million tests and labels the difference “retries” would misclassify legitimate parallel types. Conversely, counting only whether at least one response arrived would erase almost 292 million repeated queries. The useful record needs both the expected type set and the traffic beyond it.

It also needs coverage. The endpoints came through Google Ads from regions served by that system; the report names Russia as the major exception. This is broad visibility, not a probability sample of every Internet user or resolver. One dual-stack authoritative machine is a controlled instrument, not a normal multi-provider authoritative fleet. The unsigned, short-response setup removes DNSSEC validation and truncation from this test rather than proving those factors unimportant elsewhere.

The article’s own arithmetic needs a receipt

The source supplies enough raw counts to check its averages, and the check reveals two disagreements.

In the SERVFAIL section, the prose calls 51.29 the average number of queries per test and 51.59 the repeat average. The totals do not yield those values. Dividing 7,171,673,166 queries by 138,643,924 tests gives 51.7273, which the summary table reports as 51.73. Subtracting 3,702,576 “single-query” tests leaves 134,941,348 repeat-bearing tests; 6,920,490,780 repeats divided by that denominator gives 51.2852, matching the table’s 51.29.

The no-response paragraph prints its test count as 11,6050,253 and gives 82.6 queries per test. Table 1 gives 116,050,253 tests and 83.46. The table’s count produces 83.4619 when divided into 9,685,775,212 queries. Its 83.38 repeat average is likewise reproducible from 9,466,474,491 repeats divided by 113,531,062 repeat-bearing tests.

The correct response is neither to repeat the paragraph uncritically nor to pretend the discrepancy proves the experiment wrong. The raw totals, table and formulas should travel together. A reader can then distinguish a transcription or label problem from a measurement problem. Only the source author can say which prose value was intended; the arithmetic can say which values follow from the published counts.

This is a small example of the larger thesis. A polished number is not self-authenticating. Its denominator, exclusions and derivation are part of the evidence.

Earlier measurements offer hypotheses, not a missing identity

APNIC’s 2019 study examined repeated NXDOMAIN traffic in more detail. It saw timing peaks, repeats from the same apparent resolver address and bursts from groups of addresses sharing a prefix. The analysis discussed Happy Eyeballs, packet loss, aggressive timers, forwarding concentration and resolver farms. It described grouping by a common /24 or /48 as an approximation.

Those observations make several mechanisms plausible. They do not allow the 2026 aggregate to inherit a settled cause. One visible source address may front several engines. Several addresses may belong to one farm. A stub may send to two services that converge on the same recursive system. A repeated query can be present in an upstream queue while the earlier one is still active. Network loss can remove either question or answer.

The current report is candid about the gap, asking whether the repetition belongs to recursive-resolver implementations or to more complex front-end and back-end systems. That unknown should remain visible in any retelling. Hiding it would turn a research question into an implementation verdict.

Microsoft’s published client timing is useful for the same reason that it is insufficient. It shows one concrete schedule: silence can cause a Windows client to query again and expand across configured servers, while a Name Error stops that path. But APNIC did not identify its sampled clients as Windows clients or prove they followed that schedule. An implementation document can explain a possible branch; it cannot populate an unobserved field in a different experiment.

Standards define restraints without solving attribution

RFC 9520 gives recursive resolvers a clear containment duty. For one query to one server address over one transport, the resolver must not retry more than twice after the first transmission. It must cache exhausted resolution failures for at least one second and no more than five minutes, preventing matching incoming demand from generating fresh outgoing work during that interval.

Those rules address a real failure-storm risk. They still do not let an authoritative observer map every arriving packet to one RFC-level decision. A resolver may try another server address or compatible transport. Several clients may feed one recursive transaction, or one client action may fan out through several systems. A deployed implementation can comply at one tuple and still contribute many queries across a larger path set.

RFC 2308 gives NXDOMAIN and NODATA cacheable negative meaning and permits bounded server-failure caching in its older model. RFC 8914 lets an Extended DNS Error add diagnostic detail while explicitly leaving RCODE processing unchanged. These mechanisms make states more legible. They do not authorize a false negative answer merely because it attracts less traffic, and they do not identify a retry actor that was not separately instrumented.

That is the operational boundary. Response semantics influence subsequent work. Truthful semantics cannot be chosen as a traffic-shaping convenience. The party changing timers, server selection, query joining or failure caches must prove the local effect with local evidence.

Publish the path that a ratio cannot show

A layer-aware measurement receipt can stay compact. It should name the experiment window, trigger channel, coverage exclusions and exact unit of analysis. It should preserve the requested type set and the expected base count before labeling excess traffic as repetition.

It should then record the response’s wire construction, server count, address families, anycast state, supported and observed transports, DNSSEC condition, response size and truncation. Raw totals, repeat totals, formulas, rounding and distributions belong beside the headline average.

Most importantly, it should not force an answer into an unobserved field. If the stub, forwarding and recursive layers were not independently instrumented, their contribution remains unknown. Where privacy and operating boundaries permit, controlled tests can add transaction identifiers at each owned stage, record whether equivalent requests were joined, and separate retries to the same tuple from exploration of another address or transport. Where that custody cannot be obtained, the report should stop at the authoritative boundary.

The APNIC experiment has already done the difficult first part: it has made the cost difference impossible to dismiss. The next step is not a stronger adjective for “storm”. It is a measurement that can say which layer exercised which retry authority.

Sources