Jump to content

Google's Public DNS: worth it?

0
  mike-loukides's Photo
Posted Dec 06 2009 12:38 PM

I did some testing on Google's public DNS service. It's a nice idea, but it's not going to make your browsing any faster. Here are my results:

Round trip time to look up a domain using Google public DNS (8.8.8.8): roughly 75 ms

Round trip time to look up a domain using my ISP: roughly 60 ms

Round trip time to look up a doman using my private caching-only server: roughly 70 ms for the first lookup, 2 ms for subsequent lookups. Note that caching has a huge effect, which is precisely Google's argument. But there's nothing better than a local cache--you might call that the first law of caching (or maybe the second). A cache that you can only reach by crossing the internet doesn't help.

The results were surprisingly consistent; I should have saved them all (rather than juet eyeballing them), but I did hundreds of queries to a number of domains over several days.

I don't know if the difference between 75 and 60 ms is noticeable. I suspect it isn't, though at last year's Velocity conference, Google reported that users are much more sensitive to latency than I would have guessed. The difference between 75 (or 60) ms and 2 ms is very noticeable, though.

There are reasons for using Google Public DNS other than pure speed. Many ISPs do a lousy job of running DNS servers (though you could run your own, as I do). There are some problems with spamming DNS servers and some other DNS security issues that (one hopes) Google will take care of. And man, that 8.8.8.8 address is cool.

Final question: how do you set up your own nameserver? Find that out in the DNS and BND Cookbook, recipe 7.7.

Cover of DNS & Bind Cookbook
Learn more about this topic from DNS & Bind Cookbook. 

The DNS & BIND Cookbook presents solutions to the many problems faced by network administrators responsible for a name server. This title is an indispensable companion to DNS & BIND, 4th Edition, the definitive guide to the critical task of name server administration. The cookbook contains dozens of code recipes showing solutions to everyday problems, ranging from simple questions, like, "How do I get BIND?" to more advanced topics like providing name service for IPv6 addresses.

Learn More Read Now on Safari


Tags:
0 Subscribe


3 Replies

 : Dec 06 2009 03:01 PM
Interesting results, Mike!

Do you happen to know whether your queries results in cache hits, misses, or a mix? It'd only be fair to compare hits to hits and misses to misses.

For hits, most of what you'd be measuring would be roundtrip delay. I'm guessing the roundtrip delay to the Google anycast instance closest to you may only be a little less than 70 ms. I'd hope that, generally, users would see lower delay to their ISPs' name servers than to more distant networks, but I'm sure that's not always the case. And some users are closer to Google's anycast instances than other users.

I just ran a bunch of queries against 8.8.8.8 for an RRset I knew Google would have cached and saw a minimum roundtrip time of 35 ms.

To gauge whether or not you hit a cached entry or not, you can look at dig's output. Here's a cache miss:

% dig a.root-servers.net.

; <<>> DiG 9.6.0-APPLE-P2 <<>> a.root-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7082
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;a.root-servers.net. IN A

;; ANSWER SECTION:
a.root-servers.net. 604800 IN A 198.41.0.4


Note that the TTL is a nice "round" number (in DNS terms, anyway): 604800 seconds, or one week.

A cache miss will return a TTL that isn't a round number, like this one:

% dig a.root-servers.net.

; <<>> DiG 9.6.0-APPLE-P2 <<>> a.root-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44932
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;a.root-servers.net. IN A

;; ANSWER SECTION:
a.root-servers.net. 604789 IN A 198.41.0.4


(That's a query against the same name server 11 seconds later.)

It'd also be interesting to compare how long it took for Google and various ISPs to do recursive resolution of various domain names, and to compare the cache hit rate, too. Since Google claims to do prefetching of popular domain names and might use a larger cache, they might have a higher cache hit rate.
0
  FloatingBones's Photo
Posted Dec 21 2009 06:45 PM

First off, anyone running Windows should download a copy of Steve Gibson's DNS Benchmark utility ( http://www.grc.com/dns/benchmark.htm ). That will allow you to rapidly test the speed of a whole bunch of different DNS servers.

Posted Image

Results you get will be highly dependent where you are located on the Internet. From what I've heard, OpenDNS is generally faster. Registered users of the free OpenDNS service also have options on how to configure DNS behavior: what to do when an invalid domain is entered, etc.

The founder of OpenDNS commented in his blog about Google's DNS a week or so ago: http://blog.opendns....dns-google-dns/ . The chain of comments on this blog entry is very interesting and educational. OpenDNS has grown a very loyal following for their service.

All things equal, I would prefer to use a DNS service that didn't give Google any more information about what I'm doing on the Internet. The trouble is that all things may not be equal. If Google starts cloning their DNS service onto thousands of machines near the edge of the Internet (and close to users), they may able to get dramatically faster DNS service than other DNS service providers.

Increasing DNS performance can have a huge impact on Internet performance in general. Gibson's utility makes it easy for the masses to meter their DNS performance.
 : Dec 25 2009 01:56 PM
Steve talked some about findings while developing the free DNS benchmarking utility on the latest version of Security Now! (episode #228, transcript should be up at http://www.grc.com/securitynow.htm in the next few days).

The most interesting thing: users have found that using a DNS service running on a home router works very poorly. It makes far more sense to directly access the DNS services from each computer. Steve and folks who were testing the benchmark have found quite a large number of routers that can crash on particular DNS requests. This means there's the potential in the future for hackers to inject code into routers once those crashes are analyzed. Even if there were no issues with crashing, beta testers found there was no speed improvements and often larger delays in using the DNS service on home routers.