Forgot your password?
typodupeerror
Google The Internet Networking Apple Technology

Beware of Using Google Or OpenDNS For iTunes 348

Posted by timothy
from the speak-friend-and-enter-slowly dept.
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 eldavojohn (898314) * <eldavojohn.gmail@com> on Friday December 31, 2010 @12:24AM (#34718708) Journal
    First, I was able to verify this with the iTunes download. My Cox DNS was 20 seconds while my Google DNS was 2 minutes 10 seconds.

    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:

    4 12 ms 10 ms 10 ms mrfddsrj02gex070002.rd.dc.cox.net [68.100.0.145]
    5 17 ms 14 ms 12 ms ashbbprj01-ae0.0.rd.as.cox.net [68.1.0.220]
    6 12 ms 15 ms 12 ms 72.215.224.16

    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:

    4 11 ms 12 ms 14 ms mrfddsrj02gex070002.rd.dc.cox.net [68.100.0.145]
    5 13 ms 11 ms 13 ms ashbbprj01-ae0.0.rd.as.cox.net [68.1.0.220]
    6 17 ms 17 ms 13 ms ge13-1.br01.ash01.pccwbtn.net [63.218.44.125]
    7 21 ms 18 ms 12 ms akamai.ge13-4.br02.ash01.pccwbtn.net [63.218.94.142]
    8 17 ms 18 ms 13 ms a72-246-30-19.deploy.akamaitechnologies.com [72.246.30.19]

    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)

    by Timothy Brownawell (627747) <tbrownaw@prjek.net> on Friday December 31, 2010 @12:41AM (#34718852) Homepage Journal

    They only find out your IP address after it's too late.

    1. Your computer asks a DNS resolver where the server is.
    2. The DNS resolver asks Apple's (well, Akami's) DNS server where the server is.
    3. The DNS server guesses the closest server, but all it has available to work with is the address of the resolver.
    4. Your computer uses that answer to contact the server and download whatever. If it was given the wrong server, it's too late now.
  • M$ does it too... (Score:2, Informative)

    by alanshot (541117) <rurick&techondemand,net> on Friday December 31, 2010 @01:05AM (#34718998)

    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.

  • by sleeper0 (319432) on Friday December 31, 2010 @01:20AM (#34719088)

    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)

    by TooMuchToDo (882796) on Friday December 31, 2010 @03:17AM (#34719658)

    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.

  • by RobertM1968 (951074) on Friday December 31, 2010 @04:17AM (#34719970) Homepage Journal

    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...

The world is moving so fast these days that the man who says it can't be done is generally interrupted by someone doing it. -- E. Hubbard

Working...