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 _______________________________________________________________ Eric Rosenberry Sr. Network Engineer | Chief Bit Plumber iovation 111 SW Fifth Avenue Suite 3200 Portland, OR 97204 www.iovation.com<http://www.iovation.com/> The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please notify the sender by reply email and delete the message and any attachments.
Hi Eric, On 18/01/10 14:27 -0800, Rosenberry, Eric wrote:
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 -- Olaf Baumert - https://baumert.eu - olaf@baumert.eu work +49 231 9721335 private +49 231 5702579 cell +49 172 5654177
On Mon, 18 Jan 2010 14:27:30 -0800 "Rosenberry, Eric" <eric.rosenberry@iovation.com> 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>.
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. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Services such as Hulu could also be affected, certain youtube files even. D'Arcy J.M. Cain wrote:
On Mon, 18 Jan 2010 14:27:30 -0800 "Rosenberry, Eric" <eric.rosenberry@iovation.com> 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>.
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.
-- Tim Lampman Co-Owner/CTO *Broadline Networks Inc.* 57 Colborne Street West, Brantford, ON, N3T 1K6 *p.* 1-866-546-8486 *c.* 905-746-3114 www.broadlinenetworks.com <http://www.broadlinenetworks.com/> | tim@broadlinenetworks.com <mailto:tim@broadlinenetworks.com>
On Jan 18, 2010, at 5:27 PM, Rosenberry, Eric 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
Thanks.
-Eric _______________________________________________________________ Eric Rosenberry Sr. Network Engineer | Chief Bit Plumber
iovation 111 SW Fifth Avenue Suite 3200 Portland, OR 97204 www.iovation.com<http://www.iovation.com/>
The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please notify the sender by reply email and delete the message and any attachments.
-- "Beware that the most effective way for someone to decrypt your data may be with rubber hose." --- SSH 1.2.12 README
On Jan 18, 2010, at 8:22 PM, Warren Kumari wrote:
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. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Jan 18, 2010, at 8:38 PM, Steven Bellovin wrote:
On Jan 18, 2010, at 8:22 PM, Warren Kumari wrote:
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.
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. -- TTFN, patrick
On Mon, Jan 18, 2010 at 8:38 PM, Steven Bellovin <smb@cs.columbia.edu> wrote:
On Jan 18, 2010, at 8:22 PM, Warren Kumari wrote:
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 :)
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
--Steve Bellovin, http://www.cs.columbia.edu/~smb
On Jan 18, 2010, at 8:38 PM, Steven Bellovin wrote:
On Jan 18, 2010, at 8:22 PM, Warren Kumari wrote:
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....
--Steve Bellovin, http://www.cs.columbia.edu/~smb
-- She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name". -- (Terry Pratchett, Maskerade)
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 On Tue, Jan 19, 2010 at 7:23 AM, Randy Bush <randy@psg.com> wrote:
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).
you want an rfc, or you want something actually deployed by operators? randy
On Tue, Jan 19, 2010 at 09:23:41PM +0900, Randy Bush wrote:
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>
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^) -- Jim Mercer jim@reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?"
On 19/01/2010 12:13, Richard Barnes wrote:
FWIW, there has been some work in the IETF on creating protocols to allow pretty rich location information to be published in reverse DNS.
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 ;-) Andy
On Jan 18, 2010, at 5:27 PM, Rosenberry, Eric wrote:
Specifically Maxmind (http://www.maxmind.com/) thinks we are in Canada
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
participants (13)
-
Andy Davidson -
Christopher Morrow -
D'Arcy J.M. Cain -
Jed Smith -
Jim Mercer -
Olaf Baumert -
Patrick W. Gilmore -
Randy Bush -
Richard Barnes -
Rosenberry, Eric -
Steven Bellovin -
Tim Lampman -
Warren Kumari