This GeoIP topic is one of the most frequent 'help please' things posted
on the NANOG list, and often there is no recourse whatsoever, users/ISPs
are just banned and there's nobody to even complain to. The reason
operators don't like this is because the whole situation is backwards -
instead of the user or operator being asked where their users are,
somebody else is answering for them and we don't even know it's
happening until users complain they're blacklisted. If GeoIP was used to
default a country dropdown and the user was always asked what country,
there would be no problem, but it's being used as a weapon and the arms
dealers are the GeoIP providers. So when content providers take this
antagonistic approach it's no surprise that some operators are
publishing geofeeds that may not be totally honest, but there is also no
way to actually verify it and so the best source we have is the
geofeed. You can ping/traceroute all you want and you're measuring
something, but not the right thing. From my point of view, that is the
problem - instead of asking where a user is, the consumers of GeoIP data
are telling users where they are, usually with no way to override it -
the data aggregators get paid, the users and ISPs are yelling into the
void and life goes on. Often they don't even tell you where they think
you are, just that you're banned. Abdullah is responsive and seems to
care and maybe ipinfo will work with you, but the problem is still that
they're not taking the operator's word for it and that's just one GeoIP
provider. There are other adversarial approaches like capturing
location info from mobile phones and associating the IP with that -
without the user or even the ISP being consulted. All of these lead to
loss of control for the operator, punishments are dealt out based on
this data (can't watch sports, can't access local site, etc), and the
people who cause the problem (GeoIP vendors) aren't the ones that feel
the pain so there's no reason to stop.
So if we only used it for pre-filling but always asked to confirm, it
would be no problem. The problem is taking somebody else's word over
the user's or even the ISP's.
PS: What happened to being able to opt out? RFC8805 2.1.2 says: " Feed
publishers may indicate that some IP prefixes should not have any
associated geolocation information. " but this doesn't seem to be
respected by anybody either.
-Laszlo
On 1/28/26 3:34 AM, Abdullah DevRel of IPinfo via NANOG wrote:
Hi Christopher,
Thank you very much. We take about 24-48 hours to verify. This involves a
series of checks backed by active measurement. To be honest, it is quite
instantaneous. But the issue involves update cycles and cache purging. Usually
it is around 24 hours. But sometimes like ASN type verification, you have to do
much more extensive reviews but those are automated as well. So, to stay safe
we say 24-48 hours.
Failing that, fallback to manual data submitted from the network operator. As a
last record, use the Country attribute from the Whois records.
If there is noise in the active measurement data, we will definitely fall back
to geofeed. That is guaranteed. We are simply comparing the best possible data
we have. We ingest a lot of data. And we pick the best.
We also use WHOIS country. In fact, for unallocated ranges, we use the RIR
country. There is a hierarchy of fallback values that make it a good system.
This is IMO where the frustration lies with GeoIP data taking unacceptable
amounts of time to update, not using it as the first method.
We do not discourage geofeed submissions nor the geofeed. It is just that our
active measurement data is generally more accurate, verifiable, and granular
than what we observe in geofeed, on average. However, we do ingest geofeed and
will pick it up when needed.
Time to update is not a bottleneck for us; users can submit their geofeed or
correction via a simple form on our website.
— Abdullah | DevRel, IPinfo
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/[email protected]/message/GUDWVNEAABEKVGBNY34U7O4OXHVKICXL/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/[email protected]/message/4QFSGZVSOP33S2SRLOFEG5QCJ3AX5U3S/
