Slashdot Mirror
How Does the New Google DNS Perform? (and Why?)
Tarinth writes "Google just announced its new Google DNS platform. Many have viewed this as a move to increase ad revenue, or maybe capture more data. This article explores those questions, as well as the actual benchmarking results for Google DNS — showing that it is faster than many, but not nearly as fast as many others." We also recently discussed security implications of the Google Public DNS.
I ran my own set of experiments benchmarking both Google DNS and OpenDNS as well as two UK ISPs. I showed more detailed results, and infer some information about how these systems are run. http://bramp.net/blog/google-dns-benchmarked
If your ISP is like mine, they break basic DNS functionality. Instead of a correct could not find error, they serve up a page of badvertising. If you opt out of that, they serve up a page that says that it could not find, not returning the real error. If you have your iPhone connected to your home wifi, and you attempt to use the google app on your phone, it breaks the search results page...
ALL of these annoyances are fixed with gDNS.
Google is using anycast for their DNS servers. There are not just two machines at 8.8.8.8 and 8.8.4.4 as the sole DNS servers. You get a relatively close-by server. This is a tried and true technique for DNS. In fact there is a technical feature about the google approach that is neat. It is likely that google is using many of the same servers it is for search for the DNS servers as well. They are running the caching DNS at each facility, such that if one server at the facility gets a record, then any other DNS server at that facility uses that response. That is one cool way to limit the delays for someone else making a DNS request. I've not seen that mentioned much before, and that is neat. I wish slashdot comments about stories that are trying to be technical would have technical comments on them near the beginning, instead of rehashing of all this privacy stuff, for a third or fourth story.
Another approach that was mentioned a lot before is that after the DNS server provides a response, the server checks to see if time is running-out regarding the TTL. If it is and has not expired yet, it asks again and pretends that the TTL counter has begun again. This again is trying to limit a DNS delay for some poor schmuck.
Another technical detail I have not seen mentioned much is that google DNS servers are returning largely authoritive answers only, often in cases where other DNS servers do not. For example, look-up a private IPv4 such as 192.168.1.1 with google's servers and some others. Others typically return non-authoritive responses, say to RFC1918.private.net. There is a lot of subtly misconfigured software-out there, hopefully this will bring it to the fore front about dealing with non-authoritive answers more carefully.
As to regarding the performance of google DNS, from a few locations for me, seems very fast. Is faster (much) than AT&T, bit slower than comcast, bit slower than work, comparison with OpenDNS is in the noise. What is more important is that they treat all records correctly, so for example kx509 _kca._udp.REALM style SRV records are handled unlike the DNS servers from some ISPs which seem to think that DNS is only for A records.
Another interesting feature is that google DNS is playing tricks with case in DNS queries and replies as yet another stop-gap-measure against DNS cache poisoning attacks. That's clever, I believe it was proposed before, but bind folks presented some issues and left it at that.