Is Google Public DNS (for my browser, not my website) faster than your run of the mill DNS?

Question

I was looking up info on using Google DNS for our website but found info on using Google Public DNS for our local computers.

Anyone know if how much faster it is? Or a good way to measure it?

Answer 1

http://code.google.com/p/namebench/

It will compare several public DNS server(s) including Google to your current one.

Answer 2

There's also GRC's DNS benchmark. Though it looks like it's Windows only (the web page claims Linux/WINE works).

Answer 3

Using Google DNS (or OpenDNS) can have negative affects with some ISPs when you are using services (like iTunes or YouTube) that use CDN networks like Akamai to distribute content.

My understanding is that CDNs will pay to peer or co-locate with ISP networks, and route traffic from the ISP's network to the CDN via a dark fiber connection, thus avoiding Internet congestion and improving performance. The AOL Transit Data Network is an example of such a service for Road Runner cable subscribers.

IMO, using Google DNS only makes sense in these scenarios:

• If you have an awful ISP with abysmal DNS performance
• You don't download alot of media or watch internet video
• You are a laptop user that finds themselves on all sorts of random networks. The 50 people sharing a WRT-54G at a coffee shop may be hammering the caching DNS server on the router.

For me, the Upstate NY Time Warner branch runs a pretty good network, so I use ISP DNS. I think ISP DNS is going to improve anyway, as computers are getting much faster, and the crappy old boxes that typically would perform utility work like serving DNS get absorbed into VMWare clusters.

Here's a comparison of using Google DNS and ISP DNS for a YouTube video:

Google DNS

$ ping v16.lscache2.c.youtube.com
PING v16.lscache2.l.google.com (209.85.239.38): 56 data bytes
64 bytes from 209.85.239.38: icmp_seq=0 ttl=47 time=54.822 ms
64 bytes from 209.85.239.38: icmp_seq=1 ttl=47 time=59.130 ms
64 bytes from 209.85.239.38: icmp_seq=2 ttl=47 time=56.981 ms
...
64 bytes from 209.85.239.38: icmp_seq=30 ttl=47 time=64.127 ms
^C
--- 209.85.239.38 ping statistics ---
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 53.596/69.145/104.663/13.599 ms

ISP DNS

$ ping v16.lscache2.c.youtube.com
PING v16.lscache2.l.google.com (74.125.0.38): 56 data bytes
64 bytes from 74.125.0.38: icmp_seq=0 ttl=54 time=37.129 ms
64 bytes from 74.125.0.38: icmp_seq=1 ttl=54 time=26.411 ms
64 bytes from 74.125.0.38: icmp_seq=2 ttl=54 time=21.199 ms
...
64 bytes from 74.125.0.38: icmp_seq=29 ttl=54 time=25.591 ms
64 bytes from 74.125.0.38: icmp_seq=30 ttl=54 time=20.021 ms
^C
--- v16.lscache2.l.google.com ping statistics ---
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.686/24.215/37.129/4.080 ms

IMPORTANT NOTE: This is not a scientific test by any means -- other phenomena could be responsible for the different DNS result.

Answer 4

Google Public DNS (8.8.8.8 or 8.8.4.4) gives a relatively consistent response time. Using the dig utility, you can check this for yourself by typing:

dig @8.8.8.8 www.serverfault.com

At the end, you'll get something like this:

;; Query time: 67 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Feb 19 09:07:15 2010
;; MSG SIZE  rcvd: 246

Running the dig command again with dig will probably speed up the response a bit:

;; Query time: 37 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Feb 19 09:07:15 2010
;; MSG SIZE  rcvd: 246

That's because most DNS servers will cache a lookup for a server that it has go outside of itself to lookup. Popular sites will probably already be in the cache. Subsequent lookups come from the cache and get a performance boost.

When using Google's Public DNS, the difference between a full lookup and a cached lookup isn't that dramatic. However, if you are running your own (less busy) caching DNS server, you can see dramatic differences.

If you perform a lookup for a site that isn't in your cache, you may see a multi-hundred millisecond initial query time. However, once it is in the cache the lookup will likely be close to zero (0) milliseconds.

Initial query:

dig @Your.DNS.Server.IP www.serverfault.com

Which gives the following result at the end:

;; Query time: 184 msec
;; SERVER: Your.DNS.Server.IP#x53(Your.DNS.Server.IP)
;; WHEN: Fri Feb 19 09:14:19 2010
;; MSG SIZE  rcvd: 217

Subsequent query:

dig @Your.DNS.Server.IP www.serverfault.com

Which gives the following result at the end:

;; Query time: 0 msec
;; SERVER: Your.DNS.Server.IP#x53(Your.DNS.Server.IP)
;; WHEN: Fri Feb 19 09:14:19 2010
;; MSG SIZE  rcvd: 217

This close to zero (if not zero) query time will last as long as the www.serverfault.com lookup doesn't age out of your local dns server's name resolution cache.

Those numbers can add up over time. The initial lookups for an address with your DNS are probably going to be a heck of a lot longer than the initial lookup with Google Public DNS. However, the subsequent lookups (as long as they stay in the cache) will likely be significantly faster. Google Public DNS on the other hand appears consistently to range from roughly 30 milliseconds to 60 milliseconds (from our location, in non-scientific tests).

You'll have to weigh the pros and cons for yourself.

Now, funny thing, while I was testing this, I couldn't actually reach the Google Public DNS servers from my network. I'm not sure why and I'm looking into it. Luckily, we use our own servers and are not effectively knocked offline. If I was at this location and only relied solely on the Google Public DNS server, I would have serious connectivity problems until whatever the issue is is resolved. So, weigh that external dependency as well.