Constantine, I'm afraid you might be confusing the NANOG list with support@linode.com (which, incidentally, I've found to be good at providing timely assistance, more often than not). In any event, I've found that commercial GeoIP services rely on data from RIRs and the global routing table a bit less than you'd expect. I'm not finding any supporting documentation right now, however I remember reading in their FAQ that harvested website user registration data was MaxMind's primary source, which makes life particularly fun when you're a hosting shop with no real "eyeball" customers to speak of. Add to the list of challenges being allocated an aggregate block from ARIN/RIRs, and the advertising regionalized de-aggregates out of various datacenters -- itself a relatively common, and sometimes technically beneficial, practice -- as appears to be happening here with Linode. If accuracy matters, I'd suggest that you and/or your provider start by working individually with MaxMind, Quova (now Neustar?), Google (who purportedly uses Quova, but sometimes needs a kick to refresh things), and Akamai. It would be interesting to see a table of which large websites get their data from which geolocation provider(s), but this should give you a good start. Hope this helps, -a On Sat, Mar 2, 2013 at 4:58 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
Dear NANOG@,
I've had a Linode in Fremont, CA (within 173.230.144.0/20 and 2600:3c01::/32) for over a year, and, in addition to some development, I sometimes use it as an ssh-based personal SOCKS-proxy when travelling and having to use any kind of public WiFi.
Since doing so, I have noticed that most geolocation services think that I'm located in NJ (the state of the corporate headquarters of Linode), instead of Northern California (where my Linode is physically from, and, coincidentally or not, where I also happen to live, hence renting a Linode from a very specific location).
Additionally, it seems like both yelp.com and retailmenot.com block the whole 173.230.144.0/20 from their web-sites, returning some graphical "403 Forbidden" pages instead.
...
I would like to point out that 173.230.144.0/20 and 2600:3c01::/32, announced out of AS6939, are allocated by Linode from their own ARIN-assigned allocations, 173.230.128.0/19 and 2600:3C00::/30, which Linode, in turn with their other ARIN-assigned space, allocates to 4 of their distinct DCs in the US, in Dallas, Fremont, Atlanta and Newark.
However, Linode does not maintain any individual whois records of which DC they announce a given sub-allocation from. They also do not document their IPv6 assignments, either: if one of their customers misbehaves, the offended network would have no clue how to block just one customer, so, potentially, a whole set of customers may end up being blocked, through a wrong prefixlen assumption.
I've tried contacting Linode in regards to whois, giving an example of some other smaller providers (e.g. vr.org) that label their own sub-allocations within their ARIN-assigned space to contain an address of the DC where the subnet is coming from, and asked whether Linode could do the same; however, Linode informed me that they don't have any kind of mail service from the DCs they're at, and that their ARIN contact, effectively, said that they're already doing everything right in regards not having any extra whois entries with the addresses of their DC, since that would actually be wrong, as noone will be expecting mail for Linode at those addresses. (In turn, it's unclear whether a much smaller vr.org has mail service at nearly a dozen of the DCs that they have their servers at, and which they provide as the addresses in ARIN's whois, but I would guess that they do not.)
This would seem like a possible shortcoming of ARIN's policies and the whois database: with RIPE, every `netname` has a `country` associated with it, seemingly without any requirements of a mailing address where mail could be received; but with ARIN, no state is ever provided, only a mailing address. (I've also just noticed that RIPE whois now has an optional `geoloc` field in addition to the non-optional `country`.)
Now, back to ARIN: is Linode doing it right? Is vr.org doing it wrong? Are they both doing it correct, or are they both wrong?
And in regards to yelp and retailmenot; why are they blocking Linode customers in 173.230.144.0/20? I've tried contacting both on multiple occasions, and have never received any replies from yelp, but retailmenot has replied several times with a blanket "someone may have tried to scrap, spam or proxy our site from this network". I have repeatedly asked retailmenot if they'd block Verizon or AT&T if someone tries to scrap or spam their web-site from those networks, too, but have never received any replies. I have also tried contacting Linode regarding this issue, and although they were very patient and tried troubleshooting the problem, reporting that it appears that other addresses within 173.230.144.0/20 are likewise blocked, but some of their other address ranges at another DC are not, they have not been able to get in touch with anyone at yelp or retailmenot to isolate the problem.
Now, if you were operating yelp or rmn, would you not block an address range with a fishy geoloc like that of Linode? I'm somewhat convinced that 403 Forbidden stems entirely out of some logic that notes that the geoloc data is likely fishy, or which [erroneously] concludes that the address range is used for anonymity purposes.
Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp stop returning 403 Forbidden?
Cheers, Constantine.