Re: L3: Google from DC via the Netherlands?

[Stuart Henderson <stu () spacehopper org>]

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.