On 2009-02-06, Peter Beckman <beckman@angryox.com> wrote:
On Fri, 6 Feb 2009, Peter Beckman wrote:
I'm OK to that IP as well, but when I query www.google.com, I get multiple IPs, but here are the ones that in in 147:
DNS Server IP Route (for me) 205.234.170.217 (tiggee) 74.125.79.147 Amsterdam 208.67.222.222 (opendns) 64.233.183.147 Amsterdam 4.2.2.1 (verizon) 74.125.19.147 San Jose 198.6.1.3 (uu.net/verizon) 74.125.47.147 Washington DC (yay)
So someone from Google has been helpful in pointing out that the resolver IP, not YOUR IP, is the one that determines where you get routed to when you make a request for www.google.com. Which is simply due to the way things are implemented, which makes sense.
you don't show the route to the DNS servers though... the resolver's queries to the auth servers obviously aren't going to be _sourced_ from the anycast address, or the auth servers' answers would often likely end up going to the wrong instance of the resolver. so, at least in google's nameservers opinion, the outgoing address used when the name was looked-up is closer to their european site... so perhaps you have ended up querying anycast instances of resolvers close on the network to the servers with the addresses which get returned, i.e. using resolvers nearer to SJC/AMS. if that's the case, i'd be much more concerned about using a nearby resolver for my dns queries, which i use all the time, than being worried about an extra 100ms the times i use google. (ok, it's common, but nowhere near as common as querying dns). there's another possibility though; perhaps these public resolvers share caches between their various anycast instances, and it so happens that the lookup that got cached was done from a european site.