L3: Google from DC via the Netherlands?

Peter Beckman beckman at angryox.com
Fri Feb 6 19:51:06 UTC 2009


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.

  The problem is, here I am, just some guy, and 99%* of the Internet resolves
  to the same IP(s) regardless of who I ask.  But then the other 1%*, and
  this would likely be larger players who are diversified and have systems
  in multiple locations and networks, do something funky and give a
  different address depending on where your DNS server is in the network.

  Then throw in the possibility that YOUR DNS servers are anycasted for
  great justice, or at least for good reliability.  Now when you base YOUR
  answer on the caching server's IP address, well, it may not make sense.
  It seems that Tiggee and OpenDNS are anycasted, as is DNS Advantage, as
  well as some root nameservers.

  Thus my problem -- because I ask two free resolving name services, which
  I believe to be anycasted, where to go, I get routed to Amsterdam instead
  of a few miles down the road in Ashburn, VA, and spend 100ms instead of
  10ms travelling the globe, costing someone more money for Atlantic Ocean
  transit when it was unnecessary.

  SO.  Who's problem is this to fix?  Is it:

     1. Me?  Am I a dope for using a very reliable but anycasted resolving
        name service?  Clearly, I could just use the handy dandy easy to
        remember because I worked there 198.6.1.x, or is that an Internet
        faux pas because technically I wasn't given permission to use it?

     2. Google?  They probably have an interest in making sure my experience
        to their services are fast and as close to me as possible, but I'm
        probably a minority and not worth the effort of refactoring a giant
        DNS implementation just to fix my one problem, nay, inconvenience.

     3. Anycasted DNS Providers? Not sure how they could fix it, other than
        flag certain domains as special, and do something special for them,
        but man that smells like a hack.

     4. My ISP?  Does the ISP have to gripe at Google for providing bad
        results that causes traffic to go over expensive lines when it could
        have easily gone locally and much more cheaply?  I'm assuming that
        sending my traffic over the Atlantic to the Netherlands costs
        SOMEONE more money than if I had gone to a datacenter nearby, both
        physically and network-wise.

     5. Nobody?  Is it just the price the customer (me, who helps generate
        income for Google by using Google and clicking AdWords ads all day)
        pays for the reliability, redundancy and fault tolerance that Google
        has implemented?

  I think things are working as implemented -- it's not "broken," but it
  seems it could be better.  Then again, sometimes better is more expensive
  than the status quo, either in time or money or both.

  NOTE: I do not admit to knowing that 100% of what I've written is fact,
  and if you know better than I, please correct me and show me the light.

  * Numbers have no basis, just a guess.

Beckman
---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------




More information about the NANOG mailing list