Why IP Geolocation Is Often Wrong (and How Leased IPv4 Changes It)

Run your own address through an IP lookup tool and there’s a fair chance the result is off, sometimes by a city, sometimes by a country, and occasionally by a continent. This isn’t a bug in the lookup tool. It’s a property of how IP geolocation works in the first place.

IP geolocation is one of the most widely used and most widely misunderstood technologies on the internet. It decides which language a website greets you in, whether a streaming catalog unlocks, how a fraud system scores your checkout, and which “nearby” results a search engine shows. Yet none of it is based on knowing where you physically are. It’s based on inference, and the data feeding that inference is messier than most people assume.

That mess has grown in recent years for a specific reason: the way IPv4 addresses are owned, used, and moved around has changed. With the free pool of IPv4 exhausted, addresses are increasingly leased, transferred, and reassigned between organizations and across regions. Each of those moves can quietly break the assumptions geolocation databases rely on. Understanding why is the difference between treating geolocation as ground truth and treating it as what it actually is: a probabilistic estimate.

How IP geolocation actually works

There is no GPS chip in an IP address. Geolocation providers build their databases by combining several imperfect signals:

• Registration data (WHOIS / RDAP): Every block of public IP addresses is allocated by one of the five Regional Internet Registries (RIRs)—ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC—to a network operator. The registry records a registrant and a country. This is the coarsest signal: it tells you who holds the block and the country on file, not where any individual address is in use.
• Routing data (BGP): Providers observe which networks (autonomous systems) announce a block to the global routing table and where those networks peer and exchange traffic. This helps narrow the location to a network operator and, in many cases, a general region.
• Latency and infrastructure measurements: Some providers measure round-trip times from known locations or map IP addresses to data centers and points of presence to improve city-level accuracy.
• Crowdsourced and submitted data: User corrections, Wi-Fi and router databases, and network operator location feeds help fill gaps and improve geolocation estimates.

A geolocation database is the product of blending all of this and assigning each block a “most likely” location. Accuracy is genuinely good at the country level for typical residential and business connections, noticeably weaker at the city level. It degrades quickly whenever an address has recently changed hands or purpose.

Registration is not location

The single biggest source of confusion is conflating who registered an address with where the device using it sits.

A large multinational might hold one big IPv4 block registered to a single headquarters country, then route slices of it to offices and data centers on three continents. The registry still shows one country. A cloud provider might assign you an address out of a pool registered years ago to an entity in another region entirely. The registration data hasn’t caught up with the deployment, and it often never will, because updating it isn’t required for the address to function.

This is normal, not fraudulent. But it means a lookup that leans heavily on registration data can confidently report a “location” that is simply the paperwork’s country, not yours.

Why leased and transferred IPv4 is especially prone to errors

Here’s where the modern IPv4 economy enters the picture. Because no RIR can hand out fresh IPv4 blocks at scale anymore, organizations that need addresses increasingly obtain them on the secondary market, either by buying them outright through a registry-recorded transfer or by leasing them from a holder with more addresses than they currently use. Marketplaces such as IPbnb exist to connect holders of unused address space with the networks that need it.

For geolocation, this introduces a timing problem. When a block is leased or transferred:

1. The registrant on file may not change immediately or, in the case of a lease, may not change at all because the original holder still legally owns the address block.
2. The block can begin being announced by a completely different network, possibly in another country, as soon as the new user brings it online.
3. Geolocation databases update on their own schedules. They periodically refresh registration and routing data, which means an IP address may continue to appear in its previous location for days or even weeks before the change is reflected.

The result is predictable. A freshly leased block from a holder in Germany may be activated in a hosting facility in Singapore and still geolocate to Germany for weeks. Likewise, a transferred block that has moved between RIR regions can display outdated or conflicting country information across different geolocation providers because each provider weighs registration records, routing data, and measurement techniques differently. None of this means the address is "bad." It simply means the underlying geolocation databases have not yet reconciled the change.

This is also why the same IP can return different locations on two different lookup services on the same day: they’re sampling different signals, with different refresh cycles, around an address that recently changed hands. IPv4 leasing makes address space far more liquid and reusable, which is good for the internet’s capacity problem, but liquidity and accurate static geolocation pull in opposite directions, and operators need to manage that gap deliberately.

The cloud and BYOIP wrinkle

A related case is “Bring Your Own IP” (BYOIP), where an organization announces its own address space from a public cloud rather than using the provider’s pool. This is increasingly common for businesses that want to keep a consistent IP reputation as they migrate. The upside is portability; the side effect is that an address registered to the customer can suddenly originate from a hyperscaler’s region, again diverging from whatever a geolocation database last recorded. The fix is the same as for leasing: publish current location data rather than hoping the databases infer it correctly.

How databases catch up — and how to help them

The good news is that the ecosystem has a standard for exactly this problem. Geofeeds, as defined in RFC 8805, allow the party operating a block to publish a simple, machine-readable CSV file that maps prefixes to their real location (country, region, city). Major geolocation providers consume these feeds, and the RIRs now support referencing a geofeed directly from registration records. A correctly published geofeed is the single most effective way to tell the world where leased or transferred space is actually being used.

If you operate an address space, a short checklist closes most geolocation gaps:

• Publish an RFC 8805 geofeed: Reference it from your WHOIS/RDAP record and update it whenever you redeploy a block.
• Keep ROAs and routing hygiene current: Clean RPKI and consistent BGP announcements give providers reliable routing signals to work with.
• Submit corrections to major databases: Send updates to providers such as MaxMind, IP2Location, DB-IP, and others for addresses that matter to your business.
• Verify before you deploy: If you’ve just leased or transferred a block, check how it geolocates across multiple providers to ensure users and partners see the same results.

If you’re looking up an address, the lesson is the inverse: treat the result as an estimate. Country-level data is usually trustworthy; city-level data deserves skepticism; and an address that recently moved between owners may misreport entirely until the databases reconcile.