wickedjoker
07-28-2015, 07:25 PM
I found this article on DNS changes for video streaming I found it intrestresting since i see so many people talking about changing the DNS have a look at this before making those changes.
When I first read that some Apple TV users were seeing significant speed-ups when they start using a local ISP Domain Name System (DNS) server instead of continuing to use one of the universal DNS services, such as OpenDNS, DNS Advantage,or Google Public DNS, my first thought was, "That's wrong."
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."
Source:
http://www.zdnet.com/article/changing-dns-probably-wont-help-your-video-streaming/
When I first read that some Apple TV users were seeing significant speed-ups when they start using a local ISP Domain Name System (DNS) server instead of continuing to use one of the universal DNS services, such as OpenDNS, DNS Advantage,or Google Public DNS, my first thought was, "That's wrong."
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."
Source:
http://www.zdnet.com/article/changing-dns-probably-wont-help-your-video-streaming/
