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.
Only if I trust them not to fuck with it.
They only find out your IP address after it's too late.
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.
BTW - Remember when Google proposed to modify the DNS protocol to pass on the end-users IP? This is exactly why.
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)
I already do, and since my ISP censors the internet through their DNS there is no alternative to go back to them.
And a cleaned up version of my config. It doesn't involve the ISP at all but queries the root servers on the net instead.
And as long as the ISP:s doesn't filter the DNS requests to the root servers this is the way to go right now.
options {
allow-query {
127.0.0.1;
192.168.0.0/16;
};
directory "/var/named";
pid-file "/var/run/named/named.pid";
recursion yes;
dnssec-validation no;
};
key mykey. {
algorithm HMAC-MD5;
secret "** Secretas... ***";
};
zone "." {
type hint;
file "root.hints";
};
zone "int.anon.org" {
type master;
allow-update { key mykey.;};
file "int.anon.org.db";
notify yes;
};
zone "1.168.192.in-addr.arpa" {
type master;
allow-update { key mykey.;};
file "1.168.192.db";
notify yes;
};
zone "localdomain" {
type master;
file "localhost.db";
notify no;
};
zone "0.0.127.in-addr.arpa" {
type master;
file "0.0.127.db";
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "ip6.local.db";
allow-update { none; };
};
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Use your own ISP for DNS.
Do you have any tips for keeping your ISP from directing a "server not found" to one of their crappy ad-ridden search pages? I think that's a major reason people choose DNS servers that aren't at their ISP.
It's blacklisted in my router at the root domain level.
Slashdot runs so much faster, now.
WHY MUST YOU LOAD SOMETHING WHEN I'M CLOSING YOUR TAB, SLASHDOT?
Seriously, that's a bunch of bullshit.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Sure you can, Primary and secondary are setup to openDNS on my router...
I really don't understand why such a high percentage of /. readers use anything other than their own DNS server (i.e., a DNS server in or behind their router).
It's insanely trivial to install a caching DNS resolver on just about any OS and there is also custom router firmware that does this.
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.
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!
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
This is a very widespread practice now. Use your own ISP for DNS.
I prefer using a DNS provider who doesn't serve me a Yahoo powered by Bing search page if I try going to a bad URL - unlike my "own ISP".
StarTrekPhase2 - The Five Year Mission Continues!
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...
StarTrekPhase2 - The Five Year Mission Continues!