cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame?

Sun Mar 3 18:31:48 UTC 2013

Constantine,

I'm afraid you might be confusing the NANOG list with
support at 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 at 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.
>