Slashdot Mirror
Beware of Using Google Or OpenDNS For iTunes
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."
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
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?
My work here is dung.
This afternoon, I found a tool from Google Code called namebench which tests response times against multiple DNS servers and give recommendations based upon a number of query types. The results returned when checking the 'censorship tests' were interesting. Seems a number of sites (wikileaks, isohunt, stormfront) returned 'incorrect' results across DNS servers. I'm going to try this over the next couple of days and see if any of my browsing speeds improves.
MIL - I realized after a few seconds that probably stands for "Mother-In-Law", but the mechanic in me instantly interpreted it as "Malfunction Indicator Lamp."
Shortly after that I had a chuckle upon realizing that they're both things no one likes to see.
yeah, since you can't set secondary dns servers in any modern os...
Sure you can, Primary and secondary are setup to openDNS on my router...
Do they resolve wooosh.com?
Fandroids hate facts.
No, it's not particularly elegant. But on the other hand, split-horizon DNS is nothing new or magical either. Nor would I classify it as "abuse". The capability has been there since the early days of BIND.
In the DNS trade, we refer to it under the category of "stupid DNS tricks"
That said, it does have some significant advantages over other techniques.
#1, It's protocol-independent. Sure you can do intelligent redirects with HTTP, but not everything in the world is HTTP
#2, Even with HTTP, in order for it to work, you have to now change the name of the server, and often the links to internal content. Your initial request to www.domain.com will now have to be redirected to hostx.domain.com or www.location.domain.com etc., and links on the pages to content servers will also have to be altered. This can be confusing to end-users, and may require additional SSL certs. It's also a code maintenance issue.
#2a, While the renaming seems trivial on first glance, it has HUGE implications for search engines, etc, since those "local" servers will get indexed instead of a generic name
#2b, It also means that a calculation will have to be made by the web server deciding where to redirect you to, then the actual redirect, increasing load and latency. DNS solutions are "pre-computed" and thus do not have similar issues.
#2c, If you solve 2a by checking every request at every location, you make 2b much worse
#3, It's simple.
Downsides:
#1, Third-party DNS recursive services throw it off. (There is a proposed RFC that would allow for such recursives to pass the originating network in the request)
#2, It makes DNSSEC a right royal PITA (Much more than it already is)