Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Google The Internet Networking Apple Technology

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."
This discussion has been archived. No new comments can be posted.

Beware of Using Google Or OpenDNS For iTunes

Comments Filter:
  • by shentino ( 1139071 ) <shentino@gmail.com> on Friday December 31, 2010 @12:34AM (#34718800)

    Only if I trust them not to fuck with it.

  • by Excelsior ( 164338 ) on Friday December 31, 2010 @12:38AM (#34718834)

    Really? You mean on the Mac it isn't required to set up an IPhone or IPad that have no business relying on a desktop machine? You mean it isn't required I sync with it just to get Podcasts onto a device that already has internet connectivity? You mean on Mac it doesn't have a proprietary, signed procedure for syncing music to IPhone/IPod Touch/IPad, that makes it completely impossible to develop competing software without breaking the DMCA?

    Sure the "ITunes experience" doesn't suck as hard on the Mac as it does on other platforms, but it still sucks. As GP says it's malware, only I would elaborate and say its malware that malicious to an entire industry.

  • Re:Hrmmm (Score:5, Insightful)

    by Desert Raven ( 52125 ) on Friday December 31, 2010 @01:48AM (#34719246)

    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)

  • by dakohli ( 1442929 ) on Friday December 31, 2010 @02:30AM (#34719446)
    I really appreciated iTunes when it deleted all of my music from my iPhone when I synced up with a new Laptop. I thought I had authorized the computer, but then during the first sync, instead of transfering my purchased songs to the computer it just removed them from the phone. I know if was my fault somehow, I missed something along the the way. In the end, I figured that it would be just easier to get a new phone that I could control easier.

    Six months ago, I was the owner of mini-Mac, iPad and a iPhone. Now, I no longer have the Mac, (back to windows and mostly Linux), have a Galaxy S Captivate, and the newest device is a eLocity A7 Android tablet. I will not say that there haven't been some bumps in the road, but I will say I'm happier overall.

    Now, I would still recommend a Mac to some of my Family/Friends who don't like configuring their computers. In fact as one of the major techies in my family I encourage them all to adopt Macs, because then my life is a lot easier!

    -My mistakes are just those, please accept my apologies. Tks

  • by TooMuchToDo ( 882796 ) on Friday December 31, 2010 @03:00AM (#34719572)

    The problem is Akamai is using DNS to determine location, when it should be determining the geolocation of the client IP and throwing an HTTP redirect to the proper server. You can't rely on a client using the "proper" geographically-located DNS server.

  • by louarnkoz ( 805588 ) on Friday December 31, 2010 @03:26AM (#34719702)
    Load balancing based on the DNS resolver is so 1999! Even when it works, it works by chance, and does not test the actual speed between your PC and the potential servers. Compare that to Bit Torrent, which actually tests the speed of the downloads. You really wonder why Apple, and Akamai, would not use some kind of torrent technology!
  • by icebike ( 68054 ) on Friday December 31, 2010 @03:49AM (#34719824)

    Well the point of the GP's Anycast comment was that simply using 8.8.8.8 as your dns server is not sufficient to pinpoint WHERE your dns comes from.

    8.8.8.8 will resolve to different physical machines depending on the load balancing that Google is doing.

    Your dns request might be served out of California on one hit, and out of Ireland on the next hit.

    Akamai, by paying attention to where the DNS request came from is doing it fundamentally WRONG, because they could actually deny service (for national licensing reasons) based on location of the DNS server when the actual user was in a totally different (and legal) location.

  • by Anonymous Coward on Friday December 31, 2010 @04:40AM (#34720076)

    You really wonder why Apple, and Akamai, would not use some kind of torrent technology!

    Because BitTorrent is a free open protocol which Akamai would not be able to charge money for.

  • by devxo ( 1963088 ) on Friday December 31, 2010 @07:57AM (#34720696)
    A HTTP redirect system requires extra http request to be made without even knowing where the client is. You could be making that request from South Africa to North America, adding big delay.

    When 99.9% of internet users use their local ISP's DNS it just makes sense to build it like that. Sure it's not perfect for the odd geeks who have changed their DNS settings, but that is so small minority it doesn't make any sense to slow down their whole system.

    Akamai has been in this business for a very long time and has their infrastructure on datacenters all over the planet. They know what they're doing.
  • by TheRaven64 ( 641858 ) on Friday December 31, 2010 @08:25AM (#34720768) Journal

    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.

  • by vrmlguy ( 120854 ) <samwyse&gmail,com> on Friday December 31, 2010 @10:31AM (#34721362) Homepage Journal

    A HTTP redirect system requires extra http request to be made without even knowing where the client is. You could be making that request from South Africa to North America, adding big delay.

    An HTTP redirect is typically resolved in less than a second. If your download is going to take over a minute, that's less that 1% of your total download time.

    When 99.9% of internet users use their local ISP's DNS it just makes sense to build it like that. Sure it's not perfect for the odd geeks who have changed their DNS settings, but that is so small minority it doesn't make any sense to slow down their whole system.

    When your power users don't use their local ISPs, it makes sense to at least filter out those requests for special handling. Right now, if I were asked to chose a CDN, I'd have to recommend someone other that Akamai, if only because I use OpenDNS at home. If I were Akamai, I'd want to route Google and OpenDNS requests to servers that provide HTTP redirects based on the client's IP.

    Akamai has been in this business for a very long time and has their infrastructure on datacenters all over the planet. They know what they're doing.

    If they knew what they were doing, they wouldn't have this problem. Level 3 was able to grab Netflix, which indicates at least some customer dissatisfaction, and Limewire is growing at twice Akamai's rate. Do you work for Akamai, or are you a free-lance apologist?

Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.

Working...