New netblock Geolocate wrong (Google)

I just lit up a new IP netblock (assigned directly from ARIN) and the companies that provide Geolocate databases do not have the correct location information available yet.

Specifically Maxmind (http://www.maxmind.com/) thinks we are in Canada and IP2LOCATION (http://www.ip2location.com/) has no data.

For the most part this is benign or at worst slightly impacting since I often get redirected to global load balance nodes up in Canada instead of locally in the North West, however, the more major issue I am running into is that Google chooses to redirect all my users to www.google.ca<http://www.google.ca>.

So my questions to others are:

1. How do I get my data updated in all of the geolocate providers databases as quickly as possible?

2. What geolocate database does Google use (is it homegrown?) and how do I get them to update my data?

Thanks.

-Eric

Hi Eric,

So my questions to others are:
1. How do I get my data updated in all of the geolocate providers databases as quickly as possible?
2. What geolocate database does Google use (is it homegrown?) and how do I get them to update my data?

from past questions here i recall
http://nanog.cluepon.net/index.php/GeoIP
which leads to
http://www.google.com/support/websearch/bin/request.py?contact_type=ip
for google and others as well.

Regards,

Olaf

You may also find that certain things are unavailable to your users.
Sometimes sheet music or books are only available in the US for
copyright reasons.

Services such as Hulu could also be affected, certain youtube files even.

D'Arcy J.M. Cain wrote:

I just lit up a new IP netblock (assigned directly from ARIN) and the companies that provide Geolocate databases do not have the correct location information available yet.

Specifically Maxmind (http://www.maxmind.com/) thinks we are in Canada and IP2LOCATION (http://www.ip2location.com/) has no data.

For the most part this is benign or at worst slightly impacting since I often get redirected to global load balance nodes up in Canada instead of locally in the North West, however, the more major issue I am running into is that Google chooses to redirect all my users to www.google.ca<http://www.google.ca>.

So my questions to others are:

1. How do I get my data updated in all of the geolocate providers databases as quickly as possible?

2. What geolocate database does Google use (is it homegrown?) and how do I get them to update my data?

http://www.google.com/support/websearch/bin/request.py?contact_type=ip

If it is urgent / lots of users are grumping at you, feel free to send me an off-list mail including the information asked for on that page and I'll follow up internally.

Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. Based upon the sorry state of existing reverse, I'm suspecting that there is no point....

W

I don't think that that works. Apart from the problem that you allude to -- people not bothering to set it up in the first place -- IP geolocation is often used for certain forms of access control and policy enforcement. For example: "Regular Season Local Live Blackout: All live, regular season games available via MLB.TV, MLB.com At Bat 2009 and certain other MLB.com subscription services are subject to local blackouts. Such live games will be blacked out in each applicable Club's home television territory, regardless of whether that Club is playing at home or away." (http://www.mlb.com/mediacenter/). EBay has apparently used IP geolocation (poorly) to control access to certain auctions for items that are illegal in certain jurisdictions or that cannot be exported.

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

These are just ways of satisfying lawyers & courts that you at least tried to live up to your end of the bargain (licensing, laws, etc.). Since many geo-location DBs work off SWIP records, which are obviously controlled by the user, and some even use in-addrs already for info, I don't see why it wouldn't work.

Also, this is not a silver-bullet kinda problem. Every little bit helps. If even a few % of people put LOC records into the DNS, it would help some people. The danger is not of poor uptake, it's of kruft. But that is a huge danger. Just no larger than SWIP or current in-addr.

Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. Based upon the sorry state of existing reverse, I'm suspecting that there is no point....

I don't think that that works. Apart from the problem that you allude to -- people not bothering to
set it up in the first place -- IP geolocation is often used for certain forms of access control and
policy enforcement. For example: "Regular Season Local Live Blackout: All live, regular season

Sure, but I don't think that warren meant s sole signal here... having
a hint is nice :slight_smile:

games available via MLB.TV, MLB.com At Bat 2009 and certain other MLB.com subscription
services are subject to local blackouts. Such live games will be blacked out in each applicable
Club's home television territory, regardless of whether that Club is playing at home or away."
(http://www.mlb.com/mediacenter/). EBay has apparently used IP geolocation (poorly) to control
access to certain auctions for items that are illegal in certain jurisdictions or that cannot be
exported.

this describes any use of geo-location for ips though, in most cases
it's probably not half bad, but with determined 'attackers' there's
very little that can protect your spotify-music from non-swedish
folks, for instance.

Speaking of geoloc fail:
<http://forum.boxee.tv/showthread.php?t=5682>
(vpn your boxee traffic to a location more suitable to your watching desires)

(I think the users of geoloc in these cases understand they have a
95-98% success rate, and are willing to take the hit on the folks who
take an effort to avoid them.)

-Chris

Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. Based upon the sorry state of existing reverse, I'm suspecting that there is no point....

I don't think that that works. Apart from the problem that you allude to -- people not bothering to set it up in the first place -- IP geolocation is often used for certain forms of access control and policy enforcement. For example: "Regular Season Local Live Blackout: All live, regular season games available via MLB.TV, MLB.com At Bat 2009 and certain other MLB.com subscription services are subject to local blackouts. Such live games will be blacked out in each applicable Club's home television territory, regardless of whether that Club is playing at home or away." (http://www.mlb.com/mediacenter/). EBay has apparently used IP geolocation (poorly) to control access to certain auctions for items that are illegal in certain jurisdictions or that cannot be exported.

Ah, yes, sorry, I guess I didn't fully explain this...

This wouldn't (well, shouldn't) be used as an authoritative source -- it would simple be yet another signal that could be used, and would provide (if the ISP so chose) higher resolution.

If you think that the IP is in Uzbekistan and traceroutes, whois and RTT all seem to agree with that, but the published LOC type record claims that it is just down the road from you in NJ then, well, you would be silly to believe it.
Folks who are currently using geolocation for policy (like MLB.com) must[0] realize that this is a fundamentally flawed approach and is only effective against a non-determined audience, mustn't they? TOR / proxies / etc will all happily get around this blocking and seem much easier for the average user than poking at DNS.

W

[0]: Ok, they probably don't, but....

Something that I have often wondered is how folks would feel about
publishing some sort of geo information in reverse DNS (something like
LOC records, with whatever precision you like) -- this would allow the
folks that geo stuff to automagically provide the best answer, and
because you control the record, you can specify whatever resolution /
precision you like.

yes!

and smb sez:

geolocation is often used for certain forms of access control and
policy enforcement. For example: "Regular Season Local Live Blackout:
All live, regular season games available via MLB.TV, MLB.com At Bat
2009 and certain other MLB.com subscription services are subject to
local blackouts. Such live games will be blacked out in each
applicable Club's home television territory, regardless of whether
that Club is playing at home or away."

first, i don't think the proportion of in-addr hackers is anywhere near
the basic inaccuracy rate of geo-loc. so may not be of big concern. if
it is of big concern, those concerned should not believe the in-addr
hack.

given that our westin, ashburn, and infomart equipment is often
considered to be in tokyo, this would be a big win.

randy

Something that I have often wondered is how folks would feel about
publishing some sort of geo information in reverse DNS (something like
LOC records, with whatever precision you like) -- this would allow the
folks that geo stuff to automagically provide the best answer, and
because you control the record, you can specify whatever resolution /
precision you like.

yes!

FWIW, there has been some work in the IETF on creating protocols to
allow pretty rich location information to be published in reverse DNS.
Basically, you publish a NAPTR pointer to a location server [1] where
an interested client can ask for the location of a specific IP address
[2][3]. (Publishing location in this way is a requirement in several
systems for VoIP 9-1-1 around the world to allow first responders to
ask networks for location. See for example the NENA i3 architecture
in the US and a similar "Canadian i2" for Canada.)

The location representation these protocols use is a profile of the
Geospatial Markup Language, so you can represent anything from a
simple point to full GIS-like layers; you can also represent civic
addresses (i.e., postal addresses) directly.

If people are interested, let me know and I can provide pointers to
some useful open-source software.

--Richard

[1] <http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery>
[2] <http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery>
[3] <http://tools.ietf.org/html/draft-ietf-geopriv-held-identity-extensions>
[4] <http://www.nena.org/standards/technical/voip/i3-requirements>

Something that I have often wondered is how folks would feel about
publishing some sort of geo information in reverse DNS (something like
LOC records, with whatever precision you like) -- this would allow the
folks that geo stuff to automagically provide the best answer, and
because you control the record, you can specify whatever resolution /
precision you like.

yes!

FWIW, there has been some work in the IETF on creating protocols to
allow pretty rich location information to be published in reverse DNS.
Basically, you publish a NAPTR pointer to a location server [1] where
an interested client can ask for the location of a specific IP address
[2][3]. (Publishing location in this way is a requirement in several
systems for VoIP 9-1-1 around the world to allow first responders to
ask networks for location. See for example the NENA i3 architecture
in the US and a similar "Canadian i2" for Canada.)

The location representation these protocols use is a profile of the
Geospatial Markup Language, so you can represent anything from a
simple point to full GIS-like layers; you can also represent civic
addresses (i.e., postal addresses) directly.

surely, with its vast talents, the ietf can make this more complex.

after all, look at the inflate-and-embellish stupidity that made the
simple idea of bgp communities for data collecion, completely ueless,
draft-meyer-collection-communities-00.txt

</sarcasm>

i just wanna deal with a cidr block for stupid simple thing, not boil
the ocean. and we have LOC RRs. no brilliance or inventiveness needed.

randy

Just to be fair here, I appreciate that there's some additional
complexity here (not much -- I implemented a client for this yesterday
in ~80 lines of Javascript), but LOC records don't cover everything.
They're fine for stationary stuff, but not so great for anything that
moves with any frequency (unless you're willing to make the DNS really
dynamic).
--Richard

Just to be fair here, I appreciate that there's some additional
complexity here (not much -- I implemented a client for this yesterday
in ~80 lines of Javascript), but LOC records don't cover everything.
They're fine for stationary stuff, but not so great for anything that
moves with any frequency (unless you're willing to make the DNS really
dynamic).

you want an rfc, or you want something actually deployed by operators?

randy

sorta like how RFC1530, over the course of 10 years, plus some ITU fiddling,
became RFC3761

its interesting how many wheels seem to need re-inventing.

8^)

This would be good, but it must be remembered that this would only ever
be one clue about where a user actually is; for example we can not
expect people who use geo-ip to try to honour international copy rights
to ever use it.

Sadly :wink:

Andy

My employer dealt with this recently, but I am unsure who specifically they
communicated with at MaxMind. What I did notice is that once informed of the
actual location of the block, MaxMind did not mind updating their database and
kept them in the loop -- they were quite communicative. The data took a while
to update, but it did happen to my employer's satisfaction.

I'll ask the person who took care of it if he'll share his contact, but poke
them through any public means you can...they do listen, in my experience.

JS