IP geolocation: how the databases work, and how to correct them

Location databases guess where an IP address is used, from routing, measurements, registry records and what network operators tell them, and websites, streaming services and fraud checks act on those guesses. A block that changes hands often keeps its old location for weeks. The fix is a geofeed, a small file that says where each prefix is used, referenced from the block's registry record, then requests to the databases that matter, and patience: allow six weeks or more.

Who uses it, and why errors hurt

• Streaming and content rights, where location is tied to licenses, so a wrong country or a hosting flag blocks a service outright.
• Search and advertising, for language, currency and local results.
• Fraud and security checks, which flag logins from unexpected places.
• Tax, gambling and other compliance, and content delivery networks choosing a server.

The IAB's 2025 workshop on IP geolocation estimated country-level accuracy in geofeeds above 95%, found city-level accuracy much lower, and found no standard way for networks to correct third-party data. Its report names the market for used IPv4 as a cause: blocks move, and "the addresses may remain 'located' in Asia in some databases for weeks or months" after moving to Europe.

Where the databases get their data

• Registry records, weighted lowest by most. The RIPE Database's own documentation says its country: attribute "cannot be used in any reliable way to map IP addresses to countries": it is usually the holder's country, not the user's.
• Routing: which networks announce and carry the prefix.
• Measurement: latency and traceroutes from the providers' own probes.
• Reverse DNS names and network paths.
• Geofeeds that operators publish, and corrections they submit.
• Signals from devices and browsers, for some providers.

Separately from location, most providers classify addresses: hosting, VPN, proxy, Tor. These flags often decide more than the country does (below).

The geofeed file: RFC 8805

RFC 8805 defines a CSV file, one line per prefix:

# prefix,country,region,city,postal code
192.0.2.0/24,NL,NL-NH,Amsterdam,
198.51.100.0/24,DE,DE-HE,Frankfurt am Main,
203.0.113.0/24,,,,

• The prefix is required; the country is an ISO 3166-1 code, the region an ISO 3166-2 code such as NL-NH, and the city plain text.
• No postal codes: the field is deprecated, and "new feeds SHOULD NOT include" it.
• Empty fields mean no location, for space not in use yet, rather than a guess.
• The whole set every time, not changes only; the same prefix twice is an error.
• UTF-8, lines ending in CRLF, served over HTTPS.
• A hint, not an order: providers check a feed against their own data and may prefer other sources.

Pointing to the file: RFC 9632

RFC 9632, which replaced RFC 9092 in August 2024, says how a provider finds a feed and which parts it may use:

• From the registry record: a geofeed: attribute with one HTTPS address, or where a registry has none, a line in exactly the form remarks: Geofeed https://....
• The most specific record wins: a /24 assignment with its own reference overrides the reference on the /22 above it.
• Only lines inside the record's range count; the rest of the file is ignored for that record.
• The registry's own location hints are ignored once a feed exists for a range.
• Collectors fetch at most weekly, from the registries' bulk data.
• Signing a feed is optional, and unused in practice: the RPKI validator rpki-client dropped its support for checking signed feeds in January 2026, since nobody planned to use it.

At each registry

The databases and platforms

Checked on 16 October 2026. Fixing one database does not fix the others, and several large platforms run their own.

Hosting, VPN and proxy flags

A block can be in the right country and still be refused, because it is labeled as hosting or VPN space. AWS WAF's Anonymous IP list, a managed rule group a site can switch on, blocks "IP addresses from web hosting and cloud providers" unless the site overrides it; MaxMind, IP2Location and others flag hosting, VPN, proxy and Tor ranges. These labels have their own review routes, such as MaxMind's correction team form and IPQualityScore's false positive form, apart from location corrections.

A moved or leased block, step by step

1. Look it up before you take it: the main databases, their hosting and proxy flags, and every registry record covering the block for old geofeed references or location hints from earlier holders (checking a block first).
2. Decide the true location per prefix: the country always, the region and city when sure, no postal code, and empty fields for space not yet in use.
3. Publish the file over HTTPS, and check it with a validator such as geofeed-finder or MaxMind's mm-geofeed-verifier.
4. Reference it from the most specific registry record. For a lease the holder does this: it lists your prefix in its own feed, or gives your assignment its own reference to your file. Either works; ask your lessor which it does, and tell it before you move the space to another country.
5. Remove conflicting hints, such as stale geofeed references and wrong geoloc: lines.
6. Make routing agree: announce the exact prefix where its users are, with a valid ROA and route object. Space over a tunnel is placed at the tunnel's point of presence.
7. Submit to the providers that matter, with the feed's address, and ask separately for reviews of wrong hosting or VPN flags.
8. Check again after one, two and six weeks. At the end of a lease, remove or empty the block's lines, so the next user does not inherit them.

Checking where a block appears

RIPEstat answers with MaxMind's free GeoLite data for any prefix:

curl -s "https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=203.0.113.0/24"

Replace 203.0.113.0/24, a range reserved for documentation, with your block. MaxMind calls its free GeoLite City data "considerably less accurate" than its paid data, and platforms that run their own database, such as Google, are not in it. Check a few addresses on the services your users rely on as well.

How long it takes

The registry change is live at once. Collectors fetch weekly, providers review and release on their own schedules, and many websites run a downloaded copy they update when they choose. Cloudflare's own guidance for new addresses is that "IP geolocation will take at least six weeks to update across databases". No provider guarantees acceptance or timing.

Where RTM Networks fits

With every lease from us, geolocation corrections are on request: tell us where the addresses are used, and we reference a geofeed for the block from its registry record, ours or yours, and ask the main location databases to correct theirs. How fast each one follows is up to them.