Summary

  • APNIC’s optional geofeed attribute lets an authorised maintainer attach one HTTPS location-data feed to an address record.
  • The protected link proves a publication path, not the physical accuracy, completeness or freshness of every row in the external CSV.

One live registry object illustrates two different clocks. At the evidence cutoff, APNIC’s query for 206.83.119.190 returned the range 206.83.112.0 - 206.83.119.255, the maintainer MAINT-SPACEX-AP and a geofeed pointer to the separately hosted file. The object said it was last modified on 27 March 2026. The linked file, fetched separately on 26 August, carried an HTTP last-modified time from that same morning.

Those timestamps do not conflict. They describe different control surfaces. APNIC stores the pointer in an inetnum object; the network operator publishes the CSV elsewhere; geolocation providers decide when and how to consume it. The registry record can remain unchanged while the file behind its URL changes many times.

APNIC’s current inetnum guide defines geofeed as optional and single-valued: a valid HTTPS URL referring to a self-published CSV. The same guide describes mnt-by as the maintainer used to authorise and authenticate changes to the protected object. That makes the field more than an unauthenticated web hint. It provides evidence that a party able to maintain the resource record placed the link.

APNIC describes the workflow as three distinct acts: create the CSV, host it over HTTPS, and add its URL to the resource’s Whois object through MyAPNIC. Its operational guide also warns against reading the object’s country value as network location; for APNIC-maintained records, that field identifies the economy in which the organisation is legally registered. APNIC introduced Whois support for the attribute in its 18 August 2023 service announcement.

The standards preserve the same boundary. RFC 8805 defines a geofeed as an operator’s self-published mapping from prefixes to optional country, region and city data. It tells consumers to verify both the publisher’s authority and, where practical, the accuracy of the locations. It also recommends periodic refreshes—normally at least weekly when no other interval is given—because a publisher can update a feed without notification.

RFC 9632 tightens discovery and scope. Feeds must use HTTPS; unsigned rows outside the referring address range must be ignored; and a more-specific applicable object affects which feed a consumer should use. RPKI signing can provide stronger optional authentication, but even a valid signature authenticates a statement. It does not measure the place named by the statement.

The captured APNIC object and the referenced feed make the distinction visible. Within the object’s /21, the fetched file placed seven /24s and two /25s in Sydney. That is precise evidence of what the publisher asserted at the retrieval time. It is not an independent measurement of a user, satellite gateway, facility or traffic path.

A defensible consumer therefore keeps an evidence envelope: the referring object, its maintainer context, the most-specific applicable range, the URL, retrieval time, response headers, full-file hash, matching row and signature state. Cross-source checks and actual measurements then address accuracy. Without that separation, “APNIC authenticated this link” quietly becomes “APNIC verified this city”—a much stronger claim that the registry never made.

Sources