Quote:
Originally Posted by
_Rick_V_ 
As many have already said, this article is misinformed on many levels, and shows that the author doesn't really understand DNS at all.
1. DNS is simply a directory for matching human-readable names (i.e. apple.com, cnn.com, yahoo.com) with an IP address that computers understand. It doesn't have ANYTHING with setting routes (or "paths", as the author states) to/from your computer and the site!
2. the point of third-party DNS services, like Google or OpenDNS, is to speed up your surfing-- these servers are typically dramatically faster-responding than your usual ISP. Switch, and you'll see the difference.
3. Once your computer has connected to a site to download, stream, etc., DNS has no role in that process. A DNS server WILL NOT affect your download speed!
4. it is trivial for a company to block users from setting their own DNS-- simply block port 53 on the firewall (except for your main DNS server, of course). Any user setting their own DNS to anything other than the corporate DNS will be surprised to find they can no longer surf the web.
Although this article doesn't clearly identify what the real inefficiency is caused by this problem, it does exist and due to the way Akamai operates and it can have an effect if you are not using your ISP's name servers.
When you send a query for a web site to your recursive DNS server, usually your ISP's, that server in turn will query the CDN's DNS server(s) after recursing from the root zone down to the appropriate TLD zones and possibly other zones until it lands on the CDN's DNS server. Now that server doesn't know who initiated the query, but it knows the IP address of the recursive DNS server where the query came from. That CDN, Akamai for example, can have a database of IP's mapped to locations. Based on this, they will typically respond with a geographically close cluster of servers to the originating recursive DNS server. It's assumed the client who made the query to the DNS server in the first place is also reasonably close. That's where the problem can come from.
Certain recursive DNS servers also actually give you different results. OpenDNS for instance gives you a different result for google.com than most of the Internet. This is specialized for them. The purpose of that I'm not entirely certain.
Anyway, if the server you are told to connect to ends up being geographically further away, the latency is higher in reaching this server. Due to the way TCP functions (without specialized techniques like negotiated window scaling on both the server and client side), throughput is directly correlated to the latency in reaching that server. TCP is a reliable protocol, so there is an acknowledgement for each packet that is sent. If the latency is higher it takes longer to send the same number of requests and acknowledgements in the TCP stream. You can equate this to transporting boxes in your car between two towns. If you have 100 boxes to transport and can only fit 10 in your car at a time, that's 10 trips. Now if you're going between two towns that are 10 miles apart vs. 20 miles apart, it's obviously going to take you longer to transport all 100 boxes between the towns that are 20 miles apart. Equate the car to a TCP packet, the boxes to data and the miles to latency. If you got a larger vehicle to transport the boxes you could fit more and do it in less time even if the distance is further apart. This is equated to TCP window scaling.
So, all things being equal, your throughput is limited by the inherent nature of TCP and latency. I had a formula for this one time where you could calculate it exactly but I don't have it handy. UDP isn't bound by this restriction as it doesn't do any checks that data has arrived. This is why it is often used in DDOS attacks (besides the fact that it is easily spoofed). You can easily flood a pipe of any size with UDP, but you have to write the software to handle the error correction and retransmission of lost packets.
So in the end, yes it does matter if you use a DNS server other than your ISP's and it can ultimately affect throughput as the CDN will tell you to go to the server it thinks is closest to you. Is this always a limitation? Absolutely not. It depends on how the DNS service is setup. If you're using Google for example, just because you query 8.8.8.8, that doesn't mean that's a single server in a single location in the world. It's likely anycast which means many servers around the world all use that same IP address. You are just routed to the closest one. What this also means is that the queries from that server CANNOT originate from that 8.8.8.8 address to resolve things. Otherwise the responses would go to the nearest server to the authoritative DNS server for the domain being queried and you'd never get a response. All the DNS servers also have unique IP addresses that they source the queries from. It's likely that Google hasn't shared the IP information for their DNS service with the CDN's to optimally provide the best local server. Once that happens, this problem will likely go away, but Google tends to be very secretive with all of their internal network information.
Hope this helps clear things up a little and touches on topics that I believe should have been in the original article for completeness.
Also, for the record I don't use OpenDNS, Google DNS, or my ISP's DNS. I don't trust any of them because of the modifications they do to DNS results. I run my own DNS server in my home that I have complete control over, in addition to providing DNSSEC which I know my ISP's servers do not, and I'm unsure about OpenDNS or Google.
