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."
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)
Not really. An HTTP redirect means that you make an initial connection to one server, and are then told that what you really want is on another. This adds a small amount of latency, but typically well under half a second. The original server is then not used for the remainder of the download. Akamai is typically used to serve large files - at least a few megabytes - so this extra hop doesn't add much overhead, and does make the geographic distribution much more efficient.
Using the DNS server's IP to determine the address of the client is fundamentally broken. There are other cases where it can fail spectacularly, such as when you have a computer sitting on two networks - it always sends DNS requests on one and then picks the less-loaded network for other connections, so the DNS tells it to go to the right server for the DNS cache's network and the client uses the other network. You can also have serious problems with resolvers caching addresses in a laptop - if you move between two networks (e.g. 3G and WiFi) and the server's address is cached, you'll find that you're going to the wrong server.
I am TheRaven on Soylent News