Beware of Using Google Or OpenDNS For iTunes 348
Relayman writes "Joe Mailer wanted to download an iTunes movie recently and his Apple TV told him it would take two hours. When he switched his DNS resolver settings, the download time dropped to less than 20 seconds. Apparently, iTunes content is served by Akamai which uses geolocation based on the IP address of the DNS request to determine which server should provide his content. When you use Google or OpenDNS to resolve the Apple domain name, all the requests to Akamai appear to be coming from the same location and they're all directed to the same server pool, overloading that pool and causing the slow downloads. The solution: be wary of using Google or OpenDNS when downloading iTunes files or similar large files. Use your own ISP's DNS servers instead or run your own resolving DNS server."
Opposite Experience with Adobe Download (Score:5, Informative)
But I just tested this on my own by using a different source that uses Akamai: Adobe.
So I picked a file at this URL: http://ardownload.adobe.com/pub/adobe/reader/unix/9.x/9.4.0/enu/AdbeRdr9.4-1_i486linux_enu.bin [adobe.com]
Sure enough, the initial server directed me to 72.215.224.16 with this partial tracert:
Firefox told me this would take 3 Minutes and 35 Seconds.
Then, I set my DNS to the 8.8.8.8 and 8.8.4.4 addresses and tried it again. This time I was sent to 72.246.30.19 with this partial tracert:
Surprisingly, this second server that I was directed to using Google DNS only took 10 seconds to download the same file. I did it a second time and it took 30 seconds.
Now after restoring my default DNS resolution that URL continually directs me to 72.215.224.40 and the download is as speedy as the Google DNS. If I switch back to Google DNS it now continually directs me to 72.246.30.32 so you can see that there's some load balancing going here that apparently can be divvied up by geographic location for some of their customers. Apparently Apple needs to investigate the same solution that Adobe is using from Akamai. Which doesn't consider everything from Google DNS being fulfilled from a west coast replication server?
Re:You would think. (Score:5, Informative)
They only find out your IP address after it's too late.
M$ does it too... (Score:2, Informative)
Microsoft does this too. After scratching my head over the past several weeks trying to figure out why I cant download M$ files worth crap half the time, this appears to be why.
Re:Opposite Experience with Adobe Download (Score:2, Informative)
Two hours vs. instant streaming isn't a localization issue, you can easily stream 1-2mbps (or much more) from half way around the world. ~100ms in latency is nothing with a fat, non time sensitive stream like recorded video.\
It sounds like the specific POP the google DNS server is being fed is overloaded with traffic. It should be fairly easy for Apple to resolve the problem on their end, by simply not resolving to overloaded pops (they shouldn't ever anyway).
Other video cdn backed services (like netflix) don't suffer POP overloading on public DNS servers like GTE or open.
Re:You would think. (Score:4, Informative)
More info on my above point. If Akamai were to use HTTP instead of DNS for load balancing, complexity would increase in having to manage redirect clusters, as you couldn't anycast them over UDP like you can with DNS.
RFC 1546 - Host Anycasting Service
How UDP and TCP Use Anycasting
It is important to remember that anycasting is a stateless service.
An internetwork has no obligation to deliver two successive packets
sent to the same anycast address to the same host.
Because UDP is stateless and anycasting is a stateless service, UDP
can treat anycast addresses like regular IP addresses. A UDP
datagram sent to an anycast address is just like a unicast UDP
datagram from the perspective of UDP and its application. A UDP
datagram from an anycast address is like a datagram from a unicast
address. Furthermore, a datagram from an anycast address to an
anycast address can be treated by UDP as just like a unicast datagram
(although the application semantics of such a datagram are a bit
unclear).
TCP's use of anycasting is less straightforward because TCP is
stateful. It is hard to envision how one would maintain TCP state
with an anycast peer when two successive TCP segments sent to the
anycast peer might be delivered to completely different hosts.
The solution to this problem is to only permit anycast addresses as
the remote address of a TCP SYN segment (without the ACK bit set). A
TCP can then initiate a connection to an anycast address. When the
SYN-ACK is sent back by the host that received the anycast segment,
the initiating TCP should replace the anycast address of its peer,
with the address of the host returning the SYN-ACK. (The initiating
TCP can recognize the connection for which the SYN-ACK is destined by
treating the anycast address as a wildcard address, which matches any
incoming SYN-ACK segment with the correct destination port and
address and source port, provided the SYN-ACK's full address,
including source address, does not match another connection and the
sequence numbers in the SYN-ACK are correct.) This approach ensures
that a TCP, after receiving the SYN-ACK is always communicating with
only one host.
Emphasis mine.
Re:Good advice - Always use your ISP for DNS (Score:4, Informative)
So standard question. Why are you throwing unresolvable queries at your ISP's DNS??
Hmmm... here's a few guesses:
(1) typo
(2) bad link from another site
(3) dead link on a search engine
(4) checking a domain that's been registered to see if it's active, parked or pointing nowhere
I'm sure there are other reasons...