Why your leased subnet shows the wrong country, and how a geofeed fixes it

Why geolocation lags a transfer

IP geolocation is not a property of an address; it is a guess that many databases make independently, from whatever signals they can find. There is no authoritative registry of where a block physically is, because holders are under no obligation to publish it, so the databases infer location from routing data, from the holder's own country, from latency measurements, and from whatever the record said last time they looked. All of those signals lag, and some of them point at the seller.

When a range transfers or is leased to a new operator in a new country, none of those inference signals updates instantly. The routing shifts first, the registry record changes when someone updates it, and the geolocation databases catch up on their own schedules, which run from a couple of weeks to a couple of months. In the meantime the block keeps geolocating to the previous holder, because that is still the best guess the old signals support.

What it actually costs you

Wrong geolocation is not cosmetic when your business depends on where your addresses appear to be.

• Content and compliance. Users get the wrong language, the wrong currency, or content restricted to a region you are not supposed to be in.
• Access and streaming. Location-gated services refuse a range that appears to be in the wrong country, which for a VPN or proxy operator is the whole product failing.
• Fraud scoring. A mismatch between the claimed and detected country is itself a fraud signal, so a wrongly located range raises the risk score on every session from it.
• Latency and routing decisions. Anycast and CDN logic that trusts geolocation sends users to the wrong edge.

And because the databases disagree with each other, you can be correctly located by one and wrongly by another at the same time, which is why "it looks fine on the site I checked" is not the same as fixed.

Trace the wrong country to its source

Before you correct anything, understand what the databases are anchored to, because the fix is faster when you know what you are overriding. The wrong country almost always traces to the block's prior holder, and the block's history is where you see it.

Look up the prefix and read its ownership and routing past: who held it before, what country that holder sat in, and when the transfer or lease actually happened. If the range geolocates to Romania and its previous holder was a Romanian ISP that announced it for a decade, you now know exactly which signal every database is still echoing, and you can say so, with dates, when you ask them to update. This is the same history you should have read before acquiring the block; the wrong country is just another symptom of the same past, alongside any inherited reputation problems.

The fix: publish a geofeed

The durable fix is to stop letting the databases guess and tell them where the block is, in the format built for exactly this. A geofeed is a plain CSV file, defined by RFC 8805, that maps each of your prefixes to a country, region and city. You publish it at a stable HTTPS URL and, crucially, reference that URL from your RIR or RDAP record so the databases can find it on their own.

The discovery half matters as much as the file. RFC 9632 (published in 2024, updating the earlier RFC 9092) describes how a geofeed is found from and validated against the registration data, so that major geolocation providers can automatically discover and ingest a geofeed referenced in your records and re-poll it as it changes. Publish the file, reference it from the record, and you have replaced a stale inference with a signed-off statement of fact. Geofeed adoption is still modest, on the order of a fraction of a percent of allocated IPv4 space as of a couple of years ago, which means most transferred ranges are still relying on the databases to guess, and publishing one puts you ahead of that.

Nudging the databases directly

A geofeed is the systemic fix, but the big commercial databases also accept direct corrections, and using both is faster than either alone. MaxMind, for instance, has a correction form for updating the location associated with an IP or range. Submit corrections to the databases that matter to your users, keep the geofeed as the standing source of truth, and accept that downstream consumers of those databases, a cloud WAF, a CDN, an anti-fraud vendor, may lag the database itself by another cycle before they re-sync.

Then wait, and verify

Geolocation is eventually consistent, so once the geofeed is published, referenced and your corrections are in, the remaining step is patience and checking. Different databases refresh on different schedules, from days to a couple of months, so verify against several rather than the one that happens to already be right. And keep the geofeed current: the next time you move the range, re-lease it, or split it, the file is the one place you update, and everything that discovers it follows. A range whose location you actively publish is a range that stops surprising you, which is the whole point, and the same is true of everything else in its history.