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.
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.




Help










