Summary

  • APNIC's archived 05:00–06:00 UTC statistics for 29 August record 3,643,500 WHOIS queries across 5,681 origin ASNs.
  • The ASN 38661 row contains 1,412,212 queries, all classed as inetnum, and one distinct source IP. That is 38.75976396322218% of the hour, or 38.76% rounded.
  • The archive does not show the source address, queried records, response outcomes, retries, cache behaviour, rate-limit decisions, latency, bytes, purpose or service impact. The number is not evidence of abuse or of who controlled the activity.
  • APNIC can make the statistic operationally interpretable without exposing identities by publishing aggregate served, error and limited outcomes, latency and byte bands, a retry-deduplication method, the applicable threshold-policy version and a service-impact state.

The largest number in the hour is an input

The record is unusually easy to reproduce. APNIC retains hourly files in a monthly archive and publishes a checksum beside each compressed JSON file. The MD5 beside the 05:00 file is 949909ac7a74f9b609e8f2c894fa7020; recomputing the digest over the captured archive produces the same value. Inside it, the WHOIS object covers the half-open UTC interval beginning at 05:00 and ending at 06:00.

The denominator is 3,643,500 WHOIS queries from 5,681 origin ASNs. One entry, labelled ASN 38661, reports 1,412,212 queries. Its entire type distribution is inetnum, and distinct_source_ip_count is one. Dividing the row by the denominator gives 38.75976396322218%.

This is exactly the kind of visibility APNIC's prop-167 was meant to create. Before the feed, an observer could discuss directory load only through selected anecdotes or private operational knowledge. The implemented publication now permits anyone to inspect an immutable interval, test the arithmetic and compare an ASN-level row with the total.

Yet the figure records requests entering a classification system. It does not record what those requests accomplished. A query count is an input measure. It becomes an operational account only when joined to outcomes.

One address is not one actor

The phrase “one source IP” sounds more identifying than it is. A public address can front a shared resolver, proxy, NAT gateway, collection service or distributed job. One process can use several addresses; many processes can share one. The APNIC file does not publish the address, an authenticated account or a device identity. It therefore supports no conclusion about a person, customer, application or purpose.

The ASN label is also bounded. It tells readers where APNIC's aggregation placed the observed source address. It does not prove that the ASN holder commissioned the queries, controlled the originating workload or received their output. Network-resource evidence locates a record; it does not by itself assign agency.

Nor does volume settle motive. The same 1.4 million inputs could arise from an authorised bulk synchronisation, a research collection, a poorly cached client, a loop repeating failed requests, or demand that placed material pressure on the service. Those examples are scenarios, not findings. The present archive does not choose among them.

That restraint matters because a transparent feed can otherwise become an accusation machine. Publication improves accountability only if readers can distinguish what the fields prove from what a dramatic number merely suggests.

The missing half of a directory statistic

Several absent fields would change the meaning of this row without revealing the source IP or the records being looked up.

First is the outcome distribution. How many requests received a usable answer? How many produced a client error, a server error or an explicit limit response? A million successful, non-repeated requests and a million retries after failure have the same query count but describe very different systems.

Second is workload shape. Aggregate response-byte bands and latency bands would indicate whether the row represented small negative lookups, substantial records or requests that accumulated delay. A retry-deduplication method could state how APNIC groups identical requests within a short window without publishing the requests themselves.

Third is the control state. If a threshold or rate policy applied, the public record could name its version and count the requests limited under it. If no threshold action occurred, zero is useful evidence. The statistic should not assume that a limit was triggered merely because the count looks large.

Finally comes service impact. A compact state such as none observed, degradation observed, under review or not measured would separate an unusual client row from the condition of the shared service. It should carry a timestamp and correction path, because a preliminary operational assessment can change.

A receipt, not a blacklist

The appropriate public object is a privacy-safe outcome receipt for each service interval. It could retain the fields APNIC already provides—time range, service, origin ASN, query types and distinct source-IP count—and append:

  1. answered, client-error, server-error and explicitly limited totals;
  2. response-byte and latency bands rather than individual request traces;
  3. the method and window used to identify probable retries;
  4. the version of any threshold policy applied during the interval;
  5. a service-impact state with the evidence time; and
  6. a correction or supersession reference if later analysis changes the row.

This would not tell APNIC whom to block or how strict a rate limit should be. It would not turn traffic statistics into a disciplinary process. It would let operators determine whether a conspicuous numerator describes useful demand, client failure, protective control or shared-service stress.

That distinction fits a narrow registry role. APNIC can preserve a verifiable account of what its directory observed without claiming authority over motive. Operators can adapt voluntarily when evidence shows retries, poor caching or harmful load. If policy action is later proposed, it can begin from a complete record rather than a headline number.

Prop-167 succeeded—and revealed the next question

APNIC marks prop-167 implemented, with completion on 30 June 2026. The proposal called for hourly, machine-readable statistics covering source ASN, source-IP counts, service and query metadata. The 29 August archive shows that this mechanism works: a public file and checksum make a previously invisible concentration measurable.

Success changes the governance question. It is no longer enough to ask whether APNIC publishes use statistics. The question is whether their semantics permit responsible interpretation.

The current row proves a narrow and important fact: during one exact hour, APNIC counted 1,412,212 WHOIS inetnum queries in an ASN bucket containing one distinct source IP. It does not prove who acted, why the requests occurred, how many worked or whether service suffered. Publishing the missing outcomes would strengthen the achievement of prop-167. Treating the count as a verdict would weaken it.

Sources