Google公共DNS（对于我的浏览器，而不是我的网站）比你运行的DNS更快吗？

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

它会比较几个公共DNS服务器（包括谷歌）到您当前的。

还有GRC的DNS基准 。 虽然它看起来只是Windows（网页声称Linux / WINE的作品）。

当您使用像Akamai这样的CDNnetworking来分发内容的服务（如iTunes或YouTube）时，使用Google DNS（或OpenDNS）可能会对某些ISP造成负面影响。

我的理解是，CDN将支付给对等networking或与ISPnetworking共同定位，并通过暗光纤连接将stream量从ISPnetworking路由到CDN，从而避免互联网拥塞并提高性能。 美国在线公交数据网就是Road Runner有线用户这种服务的一个例子。

国际海事组织，使用谷歌DNS只在这些情况下有意义：

• 如果你有一个糟糕的ISP性能DNS糟糕
• 你不下载媒体或观看互联网video
• 你是一个笔记本电脑用户，发现自己在各种随机networking。 在咖啡店共享一台WRT-54G的50人可能正在锤击路由器上的cachingDNS服务器。

对我来说，纽约州立大学时代华纳分校运行一个非常好的networking，所以我使用ISP的DNS。 我认为，无论如何，随着计算机速度的加快，DNS DNS将会得到改善，而通常会执行像DNS服务这样的实用工作的蹩脚旧盒子将被吸收到VMWare集群中。

以下是对YouTubevideo使用Google DNS和ISP DNS的比较：

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 

重要提示：这不是以任何方式进行的科学testing – 其他现象可能导致不同的DNS结果。

Google公有DNS（8.8.8.8或8.8.4.4）提供了相对一致的响应时间。 使用dig实用工具，你可以通过input

 dig @8.8.8.8 www.serverfault.com 

最后，你会得到这样的东西：

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

用dig再次运行dig命令可能会加快响应速度：

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

这是因为大多数DNS服务器会caching一个查找服务器，它已经超出了自己的查找范围。 热门网站可能已经在caching中。 随后的查找来自caching并获得性能提升。

在使用Google的公有DNS时，完整查找和caching查找之间的区别并不那么显着。 但是，如果您正在运行自己的（不太忙）cachingDNS服务器，则可以看到显着的差异。

如果您查找不在caching中的网站，则可能会看到一个数百毫秒的初始查询时间。 但是，一旦它在caching中，查找可能接近零（0）毫秒。

初始查询：

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

最后给出如下结果：

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

后续查询：

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

最后给出如下结果：

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

这个接近零（如果不是零）的查询时间将持续，只要www.serverfault.com查找不会超出本地DNS服务器的名称parsingcaching。

这些数字会随着时间的推移而加起来 初始查找您的DNS地址可能会比使用Google Public DNS的初始查询长得多。 但是，随后的查找（只要保留在caching中）可能会显着加快。 另一方面，Google公有DNS一直显示的范围从大约30毫秒到60毫秒（从我们的位置，在非科学testing中）。

你必须权衡自己的优点和缺点。

现在，有趣的是，当我testing这个时，我实际上无法从我的networking到达Google Public DNS服务器。 我不知道为什么，我正在调查。 幸运的是，我们使用我们自己的服务器，并没有有效地脱机。 如果我在这个位置，只依靠Google Public DNS服务器，那么我将遇到严重的连接问题，直到问题得到解决。 所以，也要权衡外部依赖性。