Changing DNS probably won't help your Video Streaming
I understand their logic that "When millions of users all tap into the same DNS server addresses to resolve domain names, as Google DNS does by design, Akamai and other CDNs [Content Delivery Networks] route content to those users along the same path, preventing the network from working optimally." The problem is that this isn't really how the big DNS networks and CDNs work these days.
For starters, this proposed fix starts with the notion that your ISP has a local DNS, hence you'll get a better, less-crowded route for your video. You probably don't have a truly local DNS though. The national ISPs like Comcast. Verizon, or ATT, just like the universal DNS services, spread their DNS servers around. In this case, their DNS server isn't going to be much 'closer,' in terms of network distance than Google's.
Even if you do have a true local ISP, they may not have a local DNS. Many ISPs outsource their DNS services to DNS providers like Dynect, DNS Made Easy, or DynDNS. Still other ISPs are now using Google DNS. So, switching to your local ISP DNS may not make any difference, since its DNS server isn't actually 'local.'
It probably won't matter anyway to most users though because as David Ulevitch, OpenDNS' founder and CEO explained to me:
Many CDNs (including Akamai) have lots of tricks to do geo-targeting of users. Using DNS to target users is one of the most common ones:
When a user makes a DNS request, which happens before they make an HTTP request (for data) the path usually looks like this:
User --> ISP Recursive DNS Server --> CDN's DNS Server
With OpenDNS, it's:
User --> OpenDNS --> CDN's DNS Server
At the DNS level, CDNs don't see the User IP address, they only see the recursive DNS server asking it questions. CDNs often assume that the location of the DNS server is "near" the location of the User and so they give back a response that is near the DNS server as opposed to near the User. When the User is really far from their DNS server or on another network, this can provide suboptimal results.
But, that's not all there is to it.
There are very good solutions for this, many of which are in place today with large CDNs, including this IETF [Internet Engineering Task Force] proposal: Client IP information in DNS requests.
We do something very similar to that IETF draft proposal with folks today, and it works beautifully, actually providing an even BETTER response than just using the location of the recursive DNS server. So if more people would support proposals like that, things wouldn't just be the same, they would be even better from a performance standpoint.
The IETF and OpenDNS approach work better by giving the CDN or Web site enough information about the user's actual location to pick out the best route for the video stream. Google, which is working on the IETF proposed standard, tries currently to get around the DNS location problem by hosted "Google Public DNS in data centers worldwide, and uses anycast routing to send users to the geographically closest data center."
So, in the current Google system, "If a content provider hosts mirrored sites around the world, that provider's name-servers will return the IP address in closest proximity to the DNS resolver. … however, that because name-servers geolocate according to the resolver's IP address rather than the user's, Google Public DNS has the same limitations as other open DNS services: that is, the server to which a user is referred might be farther away than one to which a local DNS provider would have referred. This could cause a slower browsing experience for certain sites."
Page 2: [The Rest of the DNS & Streaming Story] »
The Rest of the DNS & Streaming Story
In short, most of the time, using your "local" ISP DNS probably won't help your video-streaming. As Ulevitch says, "We have arrangements with a number of CDNs that make this a non-issue. With Akamai, especially internationally, it's still suboptimal. Entirely workable, but not as optimal as it could be. North America isn't really an issue since we have a sufficiently dense network topology. That said, we're very open to working to improve end-user CDN routing with Akamai, just as we have with other large CDNs.
I'm not coming at this from just networking theory by the way. I've been streaming Internet video to my TV since before the mark 1 Apple TV showed up and today I use Apple TV, a Sony BDP-S570 Blu-ray Disc Player, and a . On them, I watch videos from Hulu Plus, Netflix, and a host of services including my own iTunes-powered video server. I've used every variety of DNS known to man, but for day-in, day-out use for my Internet TV I use both OpenDNS and Google DNS, and I've never seen a problem with that I could trace back to DNS.
I have, on the other hand, often seen trouble due to a lack of bandwidth and overwhelmed CDNs. Those problems are only going to get worse for Internet video as we literally run out of room on the Internet backbone and local pipes. I've also seen more than my fair share of video trouble from packet-drops, latency, and jitter--variation in the time between packets arriving,
I'll talk about how to deal with those network problems on another days. Suffice it for now to say that as neat as it may sound that you might be able to fix your Apple TV, Roku, or whatever media extender network problem you're seeing by just changing your DNS settings, I wouldn't count on it.
If you really want to check out your DNS performance, do what I did, and get a copy of Steve Gibson's DNS Bench. It runs on Windows, and on Linux with WINE. With it, you can find out what DNS servers work best for you in general. For details on how to switch DNS servers see my story, Fixing DNS Woes for Comcast Users and Everyone else.
Then, try streaming from iTunes or whatever video service you use and see what the best combination of DNS and video-streaming is for your location. That's more work than I suspect many people will want to go to, but if you really want to check out how much better, or not, changing DNS will be for your video streaming, it's what you need to do.