

iTunes Store Slowdowns With Google DNS - shawndumas
http://daringfireball.net/linked/2010/12/29/itunes-store-dns

======
willscott
I don't understand this at all.

Is there any reasonable theory for how the choice of DNS changes download
speed this dramatically?

I can see it taking longer to resolve the ip address of the download server,
but that should only be a one-time thing - and the total impact should be a
couple seconds at most. Unless the download is constantly flipping between
servers, I don't see how DNS latency is going to make a noticeable difference
in the time it takes to download / stream a movie.

~~~
BigZaphod
I think the deal is that it's returning an IP from the lookup based on the IP
of the DNS server that's making the request. This is so it returns a server
that's closer to your network. If your DNS request is going through Google,
it's going to return a server that's close to Google's DNS server and not your
own ISP's DNS server (which would of course be much closer to you
networkingly-speaking).

~~~
blasdel
The problem is that Apple's CDN is being extremely naive about DNS — 8.8.8.8
is not "Google's DNS server" at a particular geolocation, but many servers
distributed around the world, with different routes advertised to different
destinations depending on the client network (anycast).

Even without anycast the DNS server's geolocation is going to be way off for a
lot of ISP defaults. Why look at a cached second-party side channel instead of
the real routed packets from the client anyway? Anycast is the right mechanism
for distributing this stuff — Apple's keying off of DNS is a bad idea,
implemented poorly.

~~~
foobarbazetc
Apple's CDN is Akamai, which is definitely not "naive".

Google DNS is broken as a concept, and shouldn't have been released until they
were anycasted in either all Google CDN POPs (where ever www.google.com is
proxied from) or had talked the major CDNs (AKAM, LLNW, L3, etc) into
supporting their proposed DNS extension ([http://tools.ietf.org/html/draft-
vandergaast-edns-client-ip-...](http://tools.ietf.org/html/draft-vandergaast-
edns-client-ip-01)).

As it stands, using Google DNS is optimizing exactly the wrong thing -- it may
be "faster" than your local ISP (which I've actually never seen), but you're
trading a couple of ms on an easily scaled distributed system (which every
single ISP in the world provides) for a huge hit on network performance
because you get a non-optimal CDN pop.

I'd even go as far as saying that Google DNS is ruining the network experience
for anyone outside the US (and from Gruber's article, apparently in the US
too) -- the very problem people pay CDNs to solve in the first place.

~~~
willscott
Couldn't the CDN redirect to a closer node if DNS doesn't bring the user to an
optimal pop?

I'm pretty sure we're talking about an HTTP protocol so a 302 redirect ought
to work, and it seems like that would give the CDN way more control than
trying to distribute traffic using a cached and not reliably localized DNS
mechanism.

Edit: foobarbazetc has a good point, but it still feels like the CDN has
reasonable ways to work around and do a better job of selecting the correct
pop than DNS. Adding a layer of subdomains which force locality (us-
ny.host.com) would keep urls readable & virtual hosts intact.

~~~
foobarbazetc
Unfortunately not, because your redirect would have to use an IP address
instead of the hostname, so your browser address bar would look like:

<http://1.2.3.4/>

Which would send the wrong 'Host' header to the server, and won't serve the
right site and/or content through the CDN. :)

~~~
trotsky
apple tv

------
beej71
<http://code.google.com/speed/public-dns/faq.html#locations>

"Here are the subnets from which Google Public DNS sends requests to
authoritative nameservers, and their associated IATA airport codes"

So in theory, if you live in one of those cities, you shouldn't have this
problem. Right?

Some of the reported numbers are too astounding to be covered by this
explanation, however. I wonder if something else is at work.

------
nnutter
I can definitely attest to having this type of experience. My first time
trying to rent a movie was quite miserable. I first tried renting it from
iTunes like I do TV shows which apparently doesn't work. I then started
streaming it from the Apple TV and was greeted with these wait times a couple
times during the movie. I can't wait to try experimenting with this to see if
that was indeed the cause.

------
maguay
Anyone seen any problems with OpenDNS? iTunes Store has been running extremely
slow for me over the last several days for no apparent reason...

~~~
foobarbazetc
OpenDNS suffers from the exact same issue.

------
petercooper
Google's DNS is a pain in the ass. They either go OTT with the caching or it's
_really_ slow to deal with nameserver changes as I've encountered this myself
(when all other servers I tested were OK) and advised people on IRC with
similar issues.

------
jbrennan
I've always been a fan of:

    
    
      4.2.2.1
    

and I believe it has a family of DNS servers in a similar range. Has never let
me down (whereas my ISP, Rogers, has done so countless times).

~~~
blasdel
I use Level3's DNS servers also, but they're also distributed with anycast
routing and would likely suffer from the same interaction.

~~~
evgen
It is not the fact that they dns server is using anycast routing that is the
problem, it is the fact that the dns provider does not have a widely
distributed set of POPs. When you send out a dns query to google dns or
opendns you are going to a small set of boxes, the anycast address will route
you to the closest one in this set but it is unlikely that any of the POPs are
actually close to you. Level3 has a widely distributed set of POPs and if you
are going to use a dns service that is not provided by your ISP this is
probably the one to use.

------
jacobbijani
Mine says this with the default DNS settings too. It starts a few minutes
later anyway.

------
10smom
So how do you turn off google DNS? (If it is even on)

~~~
liuhenry
It won't be on by default, you have to enable it
(<http://code.google.com/speed/public-dns/docs/using.html>)

You can check by opening a command line (Run -> cmd) and doing a "tracert
_random web site.com_ " (or Terminal, then traceroute in OSX/mtr in linux). If
it doesn't come back with 8.8.8.8 or 8.8.4.4 as any of the servers (should be
in the first few), you're not using Google's DNS servers.

Otherwise, remove the servers and revert to automatic or ISP settings
(instructions are at the bottom of Google's doc).

EDIT: Sorry, confused DNS server with my ISP connection node. Check out the
explanation by jonburs below.

~~~
jonburs
The traceroute family doesn't show DNS info; they show intermediate routers on
the path the the resolved destination address. The early servers are the local
routers in your ISP's topology, not the DNS server used to resolve the
destination address.

A tool such as dig, on the other hand, will show you what server you're using,
and easily see the results from an alternate. For example, compare the results
of 'dig www.apple.com' (configured DNS) to 'dig www.apple.com @8.8.8.8'
(Google DNS).

~~~
liuhenry
Ah, whoops - thanks for the correction.

Quick question: dig (with no @server argument) turns up my router's IP. Is
there a way to get around that?

~~~
jonburs
That would happen if your router is providing DHCP services (common) and
returning itself as the DNS server. A good reason for that configuration is so
that you can resolve the names of other computers on your local network.

If that's the case there's a good chance your router's admin interface will
let you view and configure the DNS server its resolver is using.

