When we show the geolocation but no ASN, it is a direct consequence of how we source ASN data, and it shows up most often on a specific class of IP address. Here is the reasoning.
Where ASN data comes from in IPinfo
We do not derive ASN information from WHOIS records. We derive it from the global BGP routing table. An IP gets an ASN in our data only if a public ASN actively announces a prefix that contains that IP.
There are a few reasons we made this choice:
- WHOIS records can be stale, incomplete, or inconsistent across RIRs. The registered organization is not always the operator who is actually routing the prefix.
- Many WHOIS allocations are never announced. They are reserved, internal, or sub-allocated to entities that do not operate their own ASN.
- BGP reflects what is actually happening on the internet right now. If a packet to that IP would traverse the public internet, BGP tells us which AS receives it.
The trade-off is that any IP sitting in registered but unrouted space will have no ASN in our data, even if WHOIS shows a clear owner.
Where the geolocation comes from
Geolocation is a separate pipeline. It is built from probe RTT measurements, traceroute paths, reverse DNS, and other signals that do not require the prefix to be announced in BGP. So an IP can be reachable enough for our data sources to place it geographically, while still not appearing in any BGP announcement.
That is why the two fields can disagree: city, region, country, and even hostname can be present, while the ASN field is empty.
An example
A good illustration is 45.127.172.73. Here is what our API returns:
{
"ip": "45.127.172.73",
"hostname": "15169.syd.equinix.com",
"city": "Sydney",
"region": "New South Wales",
"country": "AU",
"loc": "-33.8678,151.2073",
"postal": "1001",
"timezone": "Australia/Sydney"
}
City, region, country, coordinates, timezone, and a descriptive hostname are all present. There is no ASN.
WHOIS shows a clear allocation:
inetnum: 45.127.172.0 - 45.127.175.255
netname: EQUINIX-AU
descr: Equinix Australia Pty Ltd
Unit B, 639 Gardeners Road, Mascot NSW 2020
country: AU
org: ORG-EAPL1-AP
status: ALLOCATED PORTABLE
mnt-by: APNIC-HM
mnt-lower: MAINT-EQUINIX-AU
source: APNIC
organisation: ORG-EAPL1-AP
org-name: Equinix Australia Pty Ltd
org-type: LIR
country: AU
The block is registered to Equinix Australia. The hostname (15169.syd.equinix.com) tells the rest of the story: this address belongs to the Equinix Sydney peering LAN, an internet exchange fabric. Peering LAN addresses are used for BGP sessions between members of the exchange, but the LAN prefix itself is not announced to the global routing table. There is no origin AS to attach to it.
This is also why a third-party WHOIS-based lookup might return AS24034 (Equinix) while a BGP-based lookup returns nothing or returns the AS of whichever member happened to leak the prefix. Different methodologies, different answers.
How to verify
If you want to confirm whether a prefix is announced before opening a ticket, two services are useful:
- RIPEstat routing-status endpoint
bgp.tools
If neither shows an active announcement covering the IP, an empty ASN field in our response is the correct answer.
When this changes
If the prefix begins to be announced (for example, the holder starts routing it through a public ASN), our pipeline picks up the announcement on the next cycle and the ASN appears. Until then, geolocation without ASN is the accurate representation of what the public internet knows about that address.