Summary

  • Tata Communications described one customer who reached French web portals even though the relevant RIR record was correct and several Geo-IP databases showed the expected location.
  • After roughly two months of follow-up, one portal's unnamed external Geo-IP supplier had still not updated its record, illustrating that registry accuracy and downstream correction are separate controls.

The interesting part of this case is not that a database was wrong. Geo-IP is an inference business; errors are inevitable. The interesting part is that the authoritative resource record was no longer the problem, yet the operator could not make the remaining error move.

At APNIC 62's Cooperation SIG, a Tata Communications presentation approached geolocation from an ISP's perspective. In the case it described, a customer was being redirected to French web portals. Tata checked the relevant RIR information and found it correct. It also checked multiple commercial or industry geolocation databases, which showed the expected result. One portal, identified in the slides as GEOLOCATION.com, still associated the address with France. The portal relied on an external Geo-IP database provider.

Tata followed the matter for about two months; according to the presentation, that provider had not applied the update. The final step sat outside Tata's direct authority.

That sequence separates three records that are often treated as one. The first is the allocation or registration record maintained through the RIR system. The second is a geolocation supplier's own dataset, assembled from several signals and refreshed on its own schedule. The third is the consuming service's deployed copy or vendor relationship. Correcting the first can strengthen the evidence available to the second. It does not compel the second to ingest it, and it does not prove that the third has received a new release.

The standards literature makes the distinction plain. RFC 8805 defines a self-published IP geolocation feed that network operators can provide. RFC 9632 describes geofeed discovery using the RPKI, while RFC 9877 specifies validation for geofeed data. Together they improve how an operator can state and authenticate a location claim. None creates an obligation for every commercial provider or relying site to refresh at a particular time.

That is why “the WHOIS record is correct” is a useful diagnostic milestone, not a closure condition. A registry can protect registration quality and make evidence discoverable. It cannot warrant every inference made by a third-party location vendor. An ISP can notify a provider and document the mismatch. It may still lack a ticket number, an update deadline, a statement of which dataset version a portal uses, or proof that the correction reached production.

The APNIC 62 conference report places the presentation in the Cooperation SIG programme, and the Tata Communications slides preserve the example. It is one case, not a measurement of provider accuracy or a finding of fault. The slides do not disclose the address block, customer, affected-user count, supplier, eventual outcome or contractual responsibility. Those absences matter: they prevent a legitimate operational example from becoming an accusation.

A recent IAB workshop report Internet-Draft describes the wider problem cautiously. It notes asynchronous and sometimes manual update practices, stale locations that may persist for weeks or months, and the absence of a standard ISP-to-provider feedback loop. The document has been sent to the RFC Editor but remains an Internet-Draft; it is neither an IETF consensus standard nor an IAB position. Its value here is descriptive: the APNIC case fits a recognised coordination failure without proving how common it is.

The smallest useful repair is a privacy-safe correction receipt. It would bind a report to a resource range or suitably minimised identifier, record the operator's asserted state and evidence, identify the provider dataset and version under review, acknowledge acceptance or rejection, and expose when the change enters the next published release. A relying portal could then state which release it consumes. No participant would need to reveal a customer identity, and no registry would be asked to become the world's location oracle.

The receipt matters because a location error can survive several apparently successful checks. A support engineer may confirm the RIR entry, attach a geofeed and reproduce the wrong destination. A supplier may acknowledge the report while holding it for its next ingestion run. The site may then cache an older commercial release. Every team can truthfully say that its own system looks healthy. Without a shared case reference and version trail, the customer has no way to distinguish a rejected claim from a queued correction or a deployed change that has not yet reached the edge.

That ambiguity also distorts escalation. Operators tend to send screenshots, traceroutes and registry links to whatever contact address they can find. Some of that evidence may be irrelevant to the provider's method; some may expose more customer detail than necessary. A structured receipt would let the supplier say which claim it evaluated and which evidence class mattered. It would also let an operator show that the authoritative registration was never the disputed element. The objective is not to force a particular geolocation result, but to make disagreement explicit and reviewable.

There is a useful division of labour here. RIR and RPKI mechanisms can authenticate control over a resource and the provenance of a published geofeed. The Geo-IP provider can decide how much weight that statement deserves alongside routing, latency, infrastructure and commercial observations. The portal can decide how fresh a dataset it is willing to buy or deploy. The receipt connects those decisions without pretending that any one of them has perfect knowledge.

The case also warns against using an RIR lookup as the sole remedy offered to users. If the lookup is already correct, sending the complainant back to the registry creates a loop rather than a solution. Support documentation should say where the location judgement actually came from, who can change it and what release cadence applies. For high-impact uses, the service should retain a human override or an alternative form of evidence while a correction is pending.

Sources

The receipt matters because a location error can survive several apparently successful checks. A support engineer may confirm the RIR entry, attach a geofeed and reproduce the wrong destination. A supplier may acknowledge the report while holding it for its next ingestion run. The site may then cache an older commercial release. Every team can truthfully say that its own system looks healthy. Without a shared case reference and version trail, the customer has no way to distinguish a rejected claim from a queued correction or a deployed change that has not yet reached the edge.

That ambiguity also distorts escalation. Operators tend to send screenshots, traceroutes and registry links to whatever contact address they can find. Some of that evidence may be irrelevant to the provider's method; some may expose more customer detail than necessary. A structured receipt would let the supplier say which claim it evaluated and which evidence class mattered. It would also let an operator show that the authoritative registration was never the disputed element. The objective is not to force a particular geolocation result, but to make disagreement explicit and reviewable.

There is a useful division of labour here. RIR and RPKI mechanisms can authenticate control over a resource and the provenance of a published geofeed. The Geo-IP provider can decide how much weight that statement deserves alongside routing, latency, infrastructure and commercial observations. The portal can decide how fresh a dataset it is willing to buy or deploy. The receipt connects those decisions without pretending that any one of them has perfect knowledge.

The case also warns against using an RIR lookup as the sole remedy offered to users. If the lookup is already correct, sending the complainant back to the registry creates a loop rather than a solution. Support documentation should say where the location judgement actually came from, who can change it and what release cadence applies. For high-impact uses, the service should retain a human override or an alternative form of evidence while a correction is pending.

Sources