Является ли Google Public DNS (для моего браузера, а не для моего веб-сайта) быстрее, чем обычный DNS?

Использование Google DNS (или OpenDNS) может иметь негативные последствия для некоторых интернет-провайдеров, когда вы используете сервисы (например, iTunes или YouTube), которые используют сети CDN, такие как Akamai, для распространения контента.

Насколько я понимаю, CDN будут платить за одноранговое соединение или совместное обнаружение с сетями интернет-провайдера и направлять трафик из сети провайдера в CDN через соединение по темному оптоволокну, что позволит избежать перегрузки в Интернете и повысить производительность. Сеть передачи данных AOL является примером такой услуги для абонентов кабельной сети Road Runner.

ИМО, использование Google DNS имеет смысл только в следующих случаях:

• Если у вас ужасный провайдер с ужасной производительностью DNS
• Вы не загружаете много средств массовой информации и не смотрите интернет-видео
• Вы - пользователь ноутбука, который обнаруживает себя во всевозможных случайных сетях. 50 человек, использующих WRT-54G в кафе, могут использовать кеширующий DNS-сервер на маршрутизаторе.

Для меня филиал Upstate NY Time Warner работает в довольно хорошей сети, поэтому я использую ISP DNS. Я думаю, что DNS ISP будет улучшаться в любом случае, так как компьютеры работают намного быстрее, а старые дрянные блоки, которые обычно выполняют служебную работу, например обслуживание DNS, поглощаются кластерами VMWare.

Вот сравнение использования Google DNS и ISP DNS для видео на YouTube:

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

Интернет-провайдер 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

ВАЖНОЕ ПРИМЕЧАНИЕ: Это ни в коем случае не является научным тестом - другие явления могут быть причиной другого DNS-результата.

Есть также DNS-тест GRC. Хотя похоже, что это только Windows (веб-страница утверждает, что Linux/WINE работает).

Google Public DNS (8.8.8.8 или 8.8.4.4) дает относительно стабильное время ответа. Используя утилиту dig, вы можете проверить это самостоятельно, набрав:

dig @8.8.8.8 www.faultserver.ru

В конце вы получите что-то вроде этого:

;; 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-серверов кэшируют поиск сервера, который он ищет вне себя. Популярные сайты, вероятно, уже будут в кеше. Последующие поиски приходят из кеша и повышают производительность.

При использовании общедоступного DNS Google разница между полным поиском и поиском в кэше не столь существенна. Однако, если вы используете свой собственный (менее загруженный) кеширующий DNS-сервер, вы можете увидеть существенные различия.

Если вы выполняете поиск сайта, которого нет в вашем кэше, вы можете увидеть начальное время запроса в несколько сотен миллисекунд. Однако, как только он будет в кеше, поиск, вероятно, будет близок к нулю (0) миллисекунд.

Начальный запрос:

dig @Your.DNS.Server.IP www.faultserver.ru

Что дает следующий результат в конце:

;; 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.faultserver.ru

Что дает следующий результат в конце:

;; 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.faultserver.ru не устареет из кэша разрешения имен вашего локального DNS-сервера.

Эти цифры могут сложиться со временем. Первоначальный поиск адреса с вашим DNS, вероятно, будет намного дольше, чем первоначальный поиск с Google Public DNS. Однако последующие поиски (пока они остаются в кэше), вероятно, будут значительно быстрее. Google Public DNS, с другой стороны, постоянно колеблется от примерно 30 миллисекунд до 60 миллисекунд (от нашего местоположения, в ненаучных тестах).

Вам придется взвесить все за и против.

Забавно, что, пока я тестировал это, я не мог получить доступ к публичным DNS-серверам Google из своей сети. Я не уверен почему, и я изучаю это. К счастью, мы используем наши собственные серверы и не работаем в автономном режиме. Если бы я находился в этом месте и полагался только на публичный DNS-сервер Google, у меня были бы серьезные проблемы с подключением, пока проблема не будет решена. Итак, взвесьте и эту внешнюю зависимость.