Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
What are you using for internal name resolution? Are the internal hosts part of an AD domain? –  joeqwerty Feb 17 '10 at 1:50

4 Answers 4

up vote 8 down vote accepted

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

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

share|improve this answer
    
pretty neat software. thanks for the link. –  einstiien Feb 16 '10 at 19:25
    
Neat software. FYI, I had to install the VC++ 2008 library files to get it to run : microsoft.com/downloads/… –  Clay Nichols Feb 16 '10 at 20:11
    
Turns out my Comcast DNS server is 25% faster than the Google server. –  Clay Nichols Feb 17 '10 at 4:38

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.

share|improve this answer

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.

share|improve this answer
2  
You forgot one more reason: if your 'usual' DNS server breaks DNS by hijacking NXDOMAIN to serve ads. –  phoebus Feb 17 '10 at 5:53
1  
...how in the hell can a DNS server affect ping round-trip time? –  grawity Feb 17 '10 at 15:44

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.