This issue will be (is?) solved with the "Client IP information in DNS requests " DNS extension[1]. A year ago, David Ulevitch (OpenDNS's owner) mentions in HN post that he already got it working for all Google properties and few other CDNs (<i>except</i> Akamai).[2]<p>[1]: <a href="http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01" rel="nofollow">http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-...</a><p>[2]: <a href="http://news.ycombinator.com/item?id=2941948" rel="nofollow">http://news.ycombinator.com/item?id=2941948</a>
This article is from 2010, back when the edns-client-subnet [1] draft wasn't even published.
I believe most CDN's are now whitelisted with Google's and OpenDNS's edns list, so you'll much better results. also see edns-client-subnet demo [2]<p>[1] <a href="http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00" rel="nofollow">http://tools.ietf.org/html/draft-vandergaast-edns-client-sub...</a>
[2] <a href="http://news.ycombinator.com/item?id=4174512" rel="nofollow">http://news.ycombinator.com/item?id=4174512</a>
This article misses one of the main reasons for people to use OpenDNS/Google DNS, which is to prevent ISP hijacking of domain names or redirection of unresolved domains.<p>I personally use it because I am extremely uncomfortable with my ISP catching mistyped URLs and redirecting me to a page filled with ads, searches, and other bogus things.
"Fairly simple to set up BIND" - well yes, for someone with access to the local gateway and the ability to install a caching DNS resolver, this is a good option.<p>Unfortunately, most crappy DNS servers are with residential ISPs - and most residential users don't run anything near an usable distro on their gateways. For a user who's <i>just</i> competent enough to change the DNS settings, the "slow CDN access" versus "spotty DNS" tradeoff will be heavily weighted towards the first option.
It's worth noting that ISP-run DNS services aren't entirely free of these issues either.<p>In Australia, both Vodaphone and (to a lesser extent) Optus resolve all DNS queries from a server farm in a single location. It is unfortunate, because mobile clients are the perfect use-case for highly localized CDNs.
This has long been an issue; particularly for Australian users where using a foreign DNS server will cause CDN requests to travel across the Pacific Ocean. This is one example (from 2010): <a href="http://apcmag.com/why-using-google-dns-opendns-is-a-bad-idea.htm" rel="nofollow">http://apcmag.com/why-using-google-dns-opendns-is-a-bad-idea...</a><p>From my location Google DNS terminates within the country - so no issue there. Not sure about OpenDNS, however.
Network neophyte here. Am I wrong in that CDN's ultimate goal is geolocation of the requestor, and they're using DNS to do that? And if the user uses a DNS that isn't "near" him, this scheme fails?<p>If that's correct, is there no better way to do user geolocation than the nameserver they choose to use? That seems weird to me.
Instead of relying on a few pings, run the test for yourself: <a href="http://code.google.com/p/namebench/" rel="nofollow">http://code.google.com/p/namebench/</a><p>The Google DNS team built the tool above, and it allows you to test your current setup against a number of DNS vendors + allows you to share the data, etc.
You should actually be using a free, fast DNS near you, with at least one not on your ISP. Here is a program to help find them:<p><a href="http://www.grc.com/dns/benchmark.htm" rel="nofollow">http://www.grc.com/dns/benchmark.htm</a>
Funny, I was wondering about this exact thing yesterday. Trying Google though (hadn't thought about other DNS providers), the traceroute went to somewhere within Europe or maybe even Amsterdam. Being from the Netherlands, that'd be very close, there just is no way 13ms is a ping from America.<p>So I guess 8.8.8.8 is multihomed or however they call it. Still, the geoIP databases claim it to be in Mountain View where Google is, so I wasn't not sure exactly how this affected 'split horizon' (on which, as far as I know, the DNS decides which IP(s) to return for the requested hostname).