Вокруг DNS, Сервера, программы, утилиты, сервисы... Налаштування

[nikelong]

У кого глючат ДНС (а это 98% пользователей ОГО) советую ознакомится с нижеследующим списком.

 

Открытые DNS - сервера:

Cisco (San Jose, CA, US)

64.102.255.44
128.107.241.185


Level 3 Communications (Broomfield, CO, US)

4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6


Verizon (Reston, VA, US)

151.197.0.38
151.197.0.39
151.202.0.84
151.202.0.85
151.202.0.85
151.203.0.84
151.203.0.85
199.45.32.37
199.45.32.38
199.45.32.40
199.45.32.43


GTE (Irving, TX, US)

192.76.85.133
206.124.64.1


SpeakEasy (Seattle, WA, US)

66.93.87.2
216.231.41.2
216.254.95.2
64.81.45.2
64.81.111.2
64.81.127.2
64.81.79.2
64.81.159.2
66.92.64.2
66.92.224.2
66.92.159.2
64.81.79.2
64.81.159.2
64.81.127.2
64.81.45.2
216.27.175.2
66.92.159.2
66.93.87.2


Sprintlink (Overland Park, KS, US)

199.2.252.10
204.97.212.10
204.117.214.10

[nikelong]

Bard,
Почему не нужно юзать опен ДНС.

В последнее время, особенно после появления Kaminsky DNS Vulnerability, стало популярным советовать сменить в настройках сети адреса DNS серверов на «безопасные и быстрые» сервера OpenDNS. Если по поводу безопасности претензий нет, то вот по быстроте хочется отметить одну важную проблему.

Вначале несколько абзацев простой теории. Многие CDN провайдеры, Google, Yahoo и другие крупные сайты обслуживают запросы пользователей сразу с помощью нескольких датацентров, для распределения нагрузки. Технически это можно реализовать четырьмя способами. Первый — использовать отдельное доменное имя для каждой зоны обслуживания датацентра. Т.е. хост www.sitename.com укажет на центральный датацентр, но на HTTP запрос (например, из России) сервер выдаст 302 редирект на russia.sitename.com. Недостаток такого решения — зависимость от центрального датацентра, некрасивые URL в строке браузера, лишний HTTP запрос и обращение к DNS. На практике такой метод не применяется.

Второй способ балансировки нагрузки — использование нескольких A записей для хоста, каждая из которых будет указывать на отдельный датацентр. Это решение может применяться в пределах города или небольшой страны, но когда ваши сервера расположены по всему миру может случиться так, что клиент из США выберет в качестве IP адрес датацентра в лондоне, увеличив задержку при обращении к серверу на 50-100 мс. На практике такой способ тоже не применяется.

Третий способ — т.н. Geo DNS. Сервера DNS, авторитетные за домен sitename.com указывают в ответе ближайший датацентр, сверяясь с базой данных по местоположению клиентского IP. Таким образом, запросы с восточного побережья США не пойдут в Европу и даже в датацентр на западном побережье, сохраняется минимальное время доступа к ресурсу. Именно такой способ балансировки применяется почти всеми крупными компаниями.

Наконец, четвертый вариант балансировки, он основывается на маршрутизации IP адресов в сети Интернет. Для определения кратчайшего маршрута от IP x.x.x.x до y.y.y.y провайдеры используют специальный протокол BGP. Для заинтересованных читателей принцип работы подробно изложен в приведенной ссылке, в кратце же, Интернет поделен на т.н. автономные системы (AS), которые соединены между собой. Каждой AS принадлежит одна или несколько IP сетей, и кратчайший путь маршрутизаторы рассчитывают по количеству промежуточных автономных систем до точки назначения. BGP, кстати, имеет кучу недостатков и проблем, но об этом уже в другой раз, пока вернемся к балансировке. Компания, владеющая сайтом sitename.com получает автономную систему, и анонсирует свою сеть одновременно во всех датацентрах. Таким образом, маршрутизатор в Европе, скорее всего, будет отправлять пакеты на IP адрес хоста www.sitename.com не в США, а скажем к ближайшему серверу в Лондоне. Почему скорее всего? Потому что как я указывал выше, BGP маршрутизация основана на определении кратчайшего маршрута по количеству промежеточных автономных систем, но не по географическому принципу. На практике может оказаться и так, что от клиента в России меньше промежуточных AS до датацентра в США, но не в Лондоне. Но в принципе, более-менее такая балансировка работает. Применяет ли кто такой способ для распределения нагрузки на веб-сервера не знаю, но вот OpenDNS использует его для распределения запросов к своим DNS, будучи подлключена напрямую к NTT (Tier 1 carrier).

Так вот проблема заключается в том, что сервера OpenDNS расположены всего в пяти датацентрах, а у Google, Yahoo и CDN провайдеров их гораздо больше. Указывая сервер OpenDNS в настройках сети на своем компьютере, IP адреса запрашиваемых хостов для пользователя определяет ближайший к нему сервер OpenDNS. Тот, в свою очередь, обращается к серверу, авторитетному для запрашиваемой зоны. И в случае использования Geo балансировки авторитетный DNS сервер вернет IP адрес датацентра, ближайшего к OpenDNS, но не пользователю! Для примера возьмем хост www.yahoo.com. Первый пинг запущен с Linux машины с локальным DNS клиентом, второй — с Windows машины с OpenDNS в качестве DNS.


debian:/tmp> ping -c 10 -n www.yahoo.com
PING www.yahoo-ht3.akadns.net (87.248.113.14) 56(84) bytes of data.
64 bytes from 87.248.113.14: icmp_seq=1 ttl=54 time=69.8 ms
64 bytes from 87.248.113.14: icmp_seq=2 ttl=54 time=72.5 ms
64 bytes from 87.248.113.14: icmp_seq=3 ttl=54 time=68.6 ms
64 bytes from 87.248.113.14: icmp_seq=4 ttl=54 time=68.8 ms
64 bytes from 87.248.113.14: icmp_seq=5 ttl=54 time=72.3 ms
64 bytes from 87.248.113.14: icmp_seq=6 ttl=54 time=87.5 ms
64 bytes from 87.248.113.14: icmp_seq=7 ttl=54 time=69.8 ms
64 bytes from 87.248.113.14: icmp_seq=8 ttl=54 time=87.4 ms
64 bytes from 87.248.113.14: icmp_seq=9 ttl=54 time=71.7 ms
64 bytes from 87.248.113.14: icmp_seq=10 ttl=54 time=74.7 ms

--- www.yahoo-ht3.akadns.net ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9131ms
rtt min/avg/max/mdev = 68.647/74.353/87.547/6.811 ms

C:\Documents and Settings\vvd>ping -n 10 www.yahoo.com

Обмен пакетами с www.yahoo-ht3.akadns.net [69.147.76.15] по 32 байт:

Ответ от 69.147.76.15: число байт=32 время=138мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=172мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=137мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=137мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=138мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=172мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=139мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=149мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=139мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=138мс TTL=53

Статистика Ping для 69.147.76.15:
Пакетов: отправлено = 10, получено = 10, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 137мсек, Максимальное = 172 мсек, Среднее = 145 мсек

Таким образом, получили разницу в RTT в 70 миллисекунд. Много это или мало, и каким образом влияет на загрузку страницы? Технически, каждый HTTP запрос к сайту Yahoo будет отрабатываться на 70 мс медленнее, что для тяжелой страницы должно дать заметное замедление. Я проверил это с помощью Firebug, и получил среднюю скорость загрузки головной страницы с OpenDNS в 6-7 секунд и 4-5 секунд с DNS местного провайдера. Каждый элемент закружается примерно на 150-200мс медленнее, и спасает только Firefox 3, поддерживающий большее чем по стандарту количество HTTP подключений к серверу.

Какой из всего написанного вывод? Используйте DNS вашего интернет провайдера! Если он уязвим к атакам, звоните и требуйте чинить. Можно поставить и свой собственный DNS клиент, но делать это стоит лишь в случае если вы не выключаете ПК на ночь или имеете домашний сервер. В противном случае, при каждом перезапуске компьютера DNS будет терять кеш и делать лишние запросы к авторитетным серверам. Это замедлит первональное обращение к сайтам и создаст дополнительную совсем не нужную нагрузку на сервера, ответственные за зоны первого уровня.