.jpg "Jobs' Mob says no to Google DNS servers -")
Steve Jobs is apparently fuming that punters are not using DNS servers that he has approved.
Many customers, even Apple fanboys, like getting off their ISPs DNS servers and use Open DNS or Google.
However, Jobs appears to think that this shows a degree of individuality and "thinking different" from the norm. Such things have to be stamped out.
As a result iTunes and the Apple TV slow down downloads from all users who dare to be original.
The problem was first noticed by Joe Maller who said that he tried to rent an iTunes movie on a newish Apple TV. Instead of starting right away, the Apple TV said it would be over two hours before he could start watching.
He knew that he had a 15-20Mbps connection and a clean wire to the Apple TV, so thought something was up. He soon found the fix. He was using Google's DNS.
Of course Maller, who can see no fault in Apple, blames Google and OpenDNS for the problem.
He points out that iTunes' video content is delivered by Akamai who has distributed massive datastores around the world so those large files originate from nearby servers and spend less time getting switched around the network.
For some reason Akamai uses DNS routing to determine location and since Google DNS and OpenDNS routes everyone to Akamai the same way, then those Akamai nodes and the pipes leading to them get clogged.
His answer was to switched to his ISP's DNS servers and now HD rentals on Apple TV are ready to watch in 10-20 seconds.
The fact that Google and Open Source anything is a complete anathema to all things Applish can be ruled out. A simple bit of network coding would have fixed the problem, but it seems that Apple and its allies would prefer that those technologically interested in changing their DNS will think the problem is with Apple's rivals.
Judging by the comments underneath Maller's bog that is exactly what most Apple fanboys believe.
In fact Google and OpenDNS servers respond quickly, it is the fault of Apple's infrastructure which uses DNS to infer a user's location, incorrectly that all its users stick to their DHCP assigned DNS servers given by their ISPs.
that's an interesting website logo with the eye of horus..
Could you send me that code? I work for Akamai, and I can put that 'simple code' into the system, if it works. Many very smart people here think this is a hard problem.
DNS is another method you can use. It's really about where you want to do the locate from. Doing from DNS servers means you have vastly fewer look ups and can cache the results.
So the next step is if you see someone using DNS from one of the major providers you do a secondary look up.
Or you could do it wrong for a large number of people on the planet. Both are options.
That's what you do on the name server -- you geolocate the requesting name server's IP address and return the IP address near the requestor for the requested web site (www.mycompany.com). That way, the customer's web site content can be oblivious of any CDN going on -- no contant needs to change. Vast majority of customers want it that way.
If you cannot georesolve on the DNS level, you will have to resolve at HTTP request level and then, maybe, forward to a different web site name (like w123.bos.us.akamai.mycompany.com). This has many problems, including that the customer web site content now has to be very aware of the CDN, especially that the content site may change its name. That may break many web technologies, including cookies, Ajax code, etc. There may be special hacks to remedy each problem, but the customers definitely would not like going that way. And why would they? To support users who want to circumvent normal network architectures?
Personally, I suspect that Google will change their DNS code to include requesting IP information, since doing otherwise makes their DNS incompatible with pretty much all CDNs, and that hurts their own users. Unless, of course, this is exactly what Google wants to get into the CDN business itself...
This is nothing to do with apple at all. The same issues will occur on Linux, or Windows.
This is 100% down to the way internet providers speed up delivery of large files - in simple terms, when you ask for the file from your ISP, they ask the file provider where it is, and the file provider gives the closest answer to your connection; nearer is faster.
When you ask for the file from google, or OpenDNS, the file provider sees the question come from google, and gives the closest answer to google; which may be many thousands of miles away from you, if you're unlucky. Further is slower.
This is just "the way it works", regardless of what operating system, laptop manufacturer or tinfoil hat brand you care to use.
In short: Article above completely misunderstands the cause, effect and technology; ignore.
But it's not at all "just how the Internet works".
DNS was never designed to be used for geolocation or route optimization, certainly not based on the location of the resolver server. I can use any DNS resolver I want to for looking up names and it's not at all "circumventing normal network architectures". It is the design of the Internet.
Misinterpreting DNS that way is just dumb. I'm surprised it works well for anyone.
Yes, serving content is a hard problem and it's impossible to do it optimally. (That's why the designers of the Internet intentionally chose not to bake it into the lower protocol layers.)
But there are surely far less broken ways to achieve the same ends.