Redirect to Google Taiwan

[fenton]

Hosts on my tunnel, 2001:470:1f05:bfe::, are being redirected by Google to google.com.tw.  Apparently that's where they think the tunnel is.  I'm wondering if this is a wider problem: if others are seeing this problem, maybe the Hurricane Electric folks can bring the issue to their attention.  Otherwise, I can report just my tunnel as being not really in Taiwan.

Anyone else seeing this?  I have had the tunnel for quite a while, and this only started fairly recently.

-Jim

[kasperd]

I am wondering if this is related to another thread: https://www.tunnelbroker.net/forums/index.php?topic=2886

What was found in that thread is, that if you lookup Google IP addresses from an HE address through Google Public DNS, you get IP addresses of a Google frontend in Sydney. It sounds plausible that Google would send taiwan users to a frontend in Sydney.

Which domain and which frontend are sort of unrelated, as the choice happens at different stages of communication. But Google may very well be using the same geolocation database for both purposes.

Could you try this command: dig google.com @google-public-dns-a.google.com

[fenton]

Sure; here's the result (I asked for the AAAA result as well since that's what's probably relevant here):

fenton@kernel:~$ dig google.com @google-public-dns-a.google.com

; <<>> DiG 9.8.1-P1 <<>> google.com @google-public-dns-a.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64838
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.         IN   A

;; ANSWER SECTION:
google.com.      300   IN   A   74.125.237.97
google.com.      300   IN   A   74.125.237.98
google.com.      300   IN   A   74.125.237.99
google.com.      300   IN   A   74.125.237.101
google.com.      300   IN   A   74.125.237.102
google.com.      300   IN   A   74.125.237.103
google.com.      300   IN   A   74.125.237.104
google.com.      300   IN   A   74.125.237.100
google.com.      300   IN   A   74.125.237.105
google.com.      300   IN   A   74.125.237.110
google.com.      300   IN   A   74.125.237.96

;; Query time: 69 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Tue May 21 10:25:41 2013
;; MSG SIZE  rcvd: 204

fenton@kernel:~$ dig google.com @google-public-dns-a.google.com aaaa

; <<>> DiG 9.8.1-P1 <<>> google.com @google-public-dns-a.google.com aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4058
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.         IN   AAAA

;; ANSWER SECTION:
google.com.      300   IN   AAAA   2404:6800:4006:803::1000

;; Query time: 46 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Tue May 21 10:26:11 2013
;; MSG SIZE  rcvd: 56

Google did an HTTP redirect to google.com.tw, so I don't think that it's directly DNS redirecting me to the wrong place, but rather that when I get there, Google decides I'm in Taiwan, and sends me the redirect. And when my wife turned IPv6 off on her PC, the problem went away.

-Jim

[kasperd]

Sure; here's the result (I asked for the AAAA result as well since that's what's probably relevant here)

Actually the A record is slightly more interesting than the AAAA record. But I only knew that, because I looked into the issue before.

What really makes a difference is if your queries to Google Public DNS goes over IPv4 or IPv6. It turns out that when you use Google Public DNS, the answers you get back depend not only on which DNS server you talk to, but also on what your client IP address is. And when your query originates from an HE IP address, Google will hand you back the IP address of a server in Sydney.

How do I know the server is in Sydney? Well, I can do a reverse DNS lookup of the IPv4 address and find the string "syd" in the name, which I assume means it is in Sydney. And I can look at the latency between me and the server, and find that it is about the time I would expect from a roundtrip to Sydney. I could do the same thing with the IPv6 address, except Google doesn't have reverse records for the IPv6 addresses.

Google did an HTTP redirect to google.com.tw, so I don't think that it's directly DNS redirecting me to the wrong place, but rather that when I get there, Google decides I'm in Taiwan, and sends me the redirect.

You are right about that. When using Google Public DNS you are really being misdirected twice, at two different layers. They may seem to have nothing to do with each other. But both are based on your IPv6 address, and I hypothesize, that they are both based on the same bad data in a geolocation database.

If Google think you are in Taiwan, then it makes sense, that they would tell you to use a webserver in Sydney. Those are roughly the same part of the world, it is plausible that Sydney is their closest webservers to Taiwan.

The incorrect choice of webserver, which makes access to Google very slow for those affected, can be avoided by not using Google Public DNS, but some other DNS server instead. For example HE has a single anycast address, you can use as your primary DNS server. If you send the query to the HE DNS server, and it goes from there to the Google authoritative DNS servers, which reply with a more reasonable answer. In that case the reply from Google will be based on the IPv4 address of the HE DNS server. The reason it is the IPv4 address, which is being used in that case is, that Google stil has no IPv6 support on their authoritative DNS servers.

You probably weren't using Google Public DNS to begin with, because if you had been, you would have experienced Google responding very slow.

The other point where you are misdirected is when you are being redirected to the wrong country domain. With a few exceptions, Google will redirect every visitor on google.com to a country specific domain. On the country specific domain, you will find a link back to google.com, which will also set a cookie, stopping the redirection in the future.

So by avoiding Google Public DNS as long as you are using an HE tunnel, and using that link back to google.com, you can avoid both of the two issues.

The only detail that I can't get to make sense yet, is why I have been able to reproduce the misdirecting DNS replies but not the redirect to google.tw. I'll have to give that another try.

[kasperd]

The only detail that I can't get to make sense yet, is why I have been able to reproduce the misdirecting DNS replies but not the redirect to google.tw. I'll have to give that another try.

I still cannot get Google to redirect me, if I connect over IPv6. Could you try the same steps as me, so we can see if this is caused by us connecting to Google from different IP addresses, or if it is something else.

Code (Over IPv4) Select Expand

telnet www.google.com 80
Trying 173.194.69.106...
Connected to www.google.com.
Escape character is '^]'.
HEAD / HTTP/1.0
Host: www.google.com

HTTP/1.0 302 Found
Location: http://www.google.dk/

Code (Over IPv6) Select Expand

telnet www.google.com 80
Trying 2a00:1450:4013:c00::6a...
Connected to www.google.com.
Escape character is '^]'.
HEAD / HTTP/1.0
Host: www.google.com

HTTP/1.0 200 OK

[broquea]

https://plus.google.com/u/0/116899029375914044550/posts/J56HMSZ316t

And there is also http://www.google.com/ncr

[fenton]

I'm apparently not the only one having this problem; I just ran across another tunnelbroker.net user reporting this at http://productforums.google.com/forum/#!topic/websearch/MpOZ6phEBlo

The other point where you are misdirected is when you are being redirected to the wrong country domain. With a few exceptions, Google will redirect every visitor on google.com to a country specific domain. On the country specific domain, you will find a link back to google.com, which will also set a cookie, stopping the redirection in the future.

This indeed works for search, but if I visit a Google Plus page such as https://plus.google.com/116899029375914044550 it will still come out in Chinese.

Here are examples of the redirect not occurring over IPv4 but happening over IPv6:

fenton@kernel:~$ telnet -4 www.google.com 80
Trying 74.125.239.116...
Connected to nuq05s01-in-f20.1e100.net.
Escape character is '^]'.
HEAD / HTTP/1.0
Host: www.google.com

HTTP/1.0 200 OK
Date: Wed, 22 May 2013 15:39:38 GMT
Expires: -1
(etc.)


fenton@kernel:~$ telnet -6 www.google.com 80
Trying 2001:4860:4001:803::1014...
Connected to www.google.com.
Escape character is '^]'.
HEAD / HTTP/1.0
Host: www.google.com

HTTP/1.0 302 Found
Location: http://www.google.com.tw/
(etc)


Google has a tool for updating the geographic location for IP address ranges at https://support.google.com/websearch/contact/ip  I could report my specific tunnel's network, but if this is a more widespread problem affecting other tunnelbroker customers it might be worthwhile for someone at he.net to make a more general report of the problem to Google.

[dawkco]

Yes, I'm having the same problem on the following subnet (which is tunneled):
2001:470:1f05:a85::/64

However, I should say that I haven't attempted to isolate this as a strictly IPv6 tunnel issue.  I'll take your words for it.

Another side effect of this issue is that wherever I see Google Ads displayed on web pages I'm browsing, some (not always all) of the ads are displayed in Chinese (presumably Taiwanese as I often see .tw in the URL's).  I am in California USA.  What is confusing about this is that not all of the ads I see are displayed in Chinese - some are displayed in English.  (Might it be possible for some ads to be coming from IPv4 sources and others from IPv6 sources?)

Update Edit:  I just tried the google.com link (lower right corner) from google.com.tw.  That seems to have gotten rid of the redirect, although I now see a link to google.com.tw where the google.com link was.  So, Google seems to be respecting a preference, but still thinks I'm in Taiwan.  Also, I'm still seeing Google Ads in Chinese, so it's not really a solution.

[kasperd]

fenton@kernel:~$ telnet -6 www.google.com 80
Trying 2001:4860:4001:803::1014...
Connected to www.google.com.
Escape character is '^]'.
HEAD / HTTP/1.0
Host: www.google.com

HTTP/1.0 302 Found
Location: http://www.google.com.tw/
(etc)

This turned out differently from in my case. So it seems the misdirection in case of DNS lookups through Google Public DNS affects more HE IPv6 addresses, than the misdirection on the HTTP requests. But both are based on mapping IPv6 address to location.

This is just strange. Even more so, considering that in the case of DNS lookups, they could do it much more reliably due to their DNS service using anycast. If they took advantage of that, they wouldn't even have to consider client IP addresses while handling DNS lookups.

I'm baffled. But clearly the issue is on the Google side. The question is, who will need to tell Google about this issue in order to make something happen. Has HE tried to give Google a complete list of prefixes used for the tunnel service and their location?

[broquea]

They had a list of what prefixes were located in what region back when they whitelisted dns servers. HE should be able to provide that again to Google if Google can do anything with it for the not-whitelisted stuff. I used to just email Google about broker user complaints and a few hours/days later it would be resolved. Pretty sure someone at HE can do that too. Can supply email if it isn't obvious to them.

[ingber]

I reported this to he.net on 9 May 2013.  Support tried to be helpful, but basically I was told that "sh*t happens".

I also contacted google support, and they admitted they could not help.  I filed a form with them wherein it was explained that it could take a month for them to get to such cases, if they could be fixed.

However, I tried using Iexplorer, Firefox, and Chrome, to several sites, not just google, and using google dns as well as opendns, on two independent PCs behind my router that is registering this tunnel.  The real problem is that the tunnel broker IPv6 address is just not being registered worldwide properly.

I still have this annoying problem as of today.

I think everyone posting here should file a ticket with he.net support.  They are the best hope for correcting their own IP addresses.

[fenton]

I opened a ticket as you suggested, and received the following reply from he.net:

Google has had the location of each tunnel server, and which prefixes
are associated with each one, but why they're not using that information
now, I don't know.  We've reached out to them, but haven't had a reply
as of yet.  Wouldn't hurt to let them know that their geolocation is not
working properly, in any case.

So he.net is indeed trying, but it wouldn't hurt for us to send reports to Google as well. Once again, the reporting address is:

https://support.google.com/websearch/contact/ip

[fenton]

So he.net is indeed trying, but it wouldn't hurt for us to send reports to Google as well. Once again, the reporting address is:

https://support.google.com/websearch/contact/ip

I did this, and gave 2001:470:1f05:bfe::/64 as the address which it didn't accept.  My immediate reaction was, "oh great, they don't understand IPv6 addresses" but it did accept 2001:470:1f05:bfe:: which hopefully they will interpret as a /64.

But who knows what they'll do with a /48.

[dawkco]

I did this, and gave 2001:470:1f05:bfe::/64 as the address which it didn't accept.  My immediate reaction was, "oh great, they don't understand IPv6 addresses" but it did accept 2001:470:1f05:bfe:: which hopefully they will interpret as a /64.

But who knows what they'll do with a /48.

I had the same problem trying to use a prefix, so I just entered the exact specific IP's (e.g., 2001:470:1f05:a85::6, ... etc.).  Luckily I only had a few to enter.

[ingber]

I finally got some rationale verification from someone at Google support:

"I asked the geo location team here and they are aware of the problem and are working on a solution. Many IPs behind he.net are indeed from Taiwan so it is complicated to distinguish the location of each individual IP."

My take on this is that this problem may not have been caused by Google, but once the nameservers log the incorrect geolocation, it is hard to fix; note that I mentioned I had the same problem when I changed all my DNS setting to OpenDNS instead of Google DNS.   Since Google likely is the largest nameserver, affecting many Google users, it makes sense for them to try to fix it.

I think more people should file the reports to Google:
https://support.google.com/websearch/contact/ip
Note that you should use just one full address, no masks; they can figure that out.

Lester

I reported this to he.net on 9 May 2013.  Support tried to be helpful, but basically I was told that "sh*t happens".

I also contacted google support, and they admitted they could not help.  I filed a form with them wherein it was explained that it could take a month for them to get to such cases, if they could be fixed.

However, I tried using Iexplorer, Firefox, and Chrome, to several sites, not just google, and using google dns as well as opendns, on two independent PCs behind my router that is registering this tunnel.  The real problem is that the tunnel broker IPv6 address is just not being registered worldwide properly.

I still have this annoying problem as of today.

I think everyone posting here should file a ticket with he.net support.  They are the best hope for correcting their own IP addresses.