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 is a very widespread practice now. Use your own ISP for DNS.
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.
They only find out your IP address after it's too late.
The beauty of the DNS "trick" is that a user requesting say "yadiyadi.com/media/cheez.mp4" in Norway would get one IP and a client in say Australia would get a completely different IP. This makes the whole CDN implementation a whole lot easier as you avoid the whole negotiation issue by having the domain resolve to different IPs based on the source of the request.
This is overly simplified of course.
It works for the vast majority of users too.
Elegant? Misusing DNS to make a CDN faster isn't elegant.
You don't need to install iTunes to install QuickTime. Sadly, you do need QuickTime to install iTunes. Which is the lessor evil depends on your needs, but I'd be thrilled to have iTunes alone without QuickTime, Bonjour or the host of kernel mode crap it installs.
Give a man a fish, he'll eat for a day, but teach a man to phish...
Right... Without DRM, but with a watermark (in other words, if you download a Miley Cyrus song and share it, anyone else who gets access to it can track it back to you)
That being said, I have a lot of trouble getting upset over the fact that purchased content is watermarked. As long as I'm not distributing the content, who cares?
Give a man a fish, he'll eat for a day, but teach a man to phish...
Seems like it would be useful to use multiple DNS servers and then choose whichever one has the fastest download and abandon the other connections.
Do any browsers/OSs/whatever have this feature? As I understand it, the secondary DNS feature only uses the secondary server when the primary server is down.
It must be Apple's "magic" that's causing the trouble.
No, it is not Apple's fault. Anyone using Akamai would have the same problem. I think Microsoft use them for Windows Updates too.
This applies to tons of GEO-optimized services and has been this way since day one. Really, how is this news?
Which is the lessor evil depends on your needs,
Well, since neither Quicktime or iTunes is leased to you, I guess that means neither is a lessor evil.
... and then they built the supercollider.
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)
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.
You can anycast DNS with UDP and the client never knows the difference since it's handled with BGP and IP. HTTP redirects would be much more difficult to do from a reliability and scalability standpoint. Also, when it fails, it would be much less graceful.
The first suggestion is just no longer an option, for so many reasons, all of them based on lack of trustworthiness in this climate of corporate dominance and machination. I was using OpenDNS for several years, but recently I started using TreeWalk to host my own modest DNS server. Seems to work fine, and I don't even notice it's there.
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!
Elegant is over-rated. DNS is a great place to implement some good value trickery for 99.99% of customers.
WTF is iTunes?
It's the virus that is installed when you update Quicktime.
War as we knew it was obsolete
Nothing could beat complete denial
- Emily Haines