Почему не надо использовать OpenDNS

09.08.2008 от vvd

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

Рубрики: Интернет | Комментарии (2) »

Южная Осетия — информационная война

09.08.2008 от vvd

Еще хочется написать про то безобразие на информационном поле, которое сегодня началось по ТВ и, что ужасно, в Интернет. В осетино-грузинском конфликте (а теперь и российско-грузинской войне)  я на стороне Тбилиси, и достаточно спокойно отношусь к однобокости освещения конфликта со стороны российских СМИ. Россия ведь теперь активная сторона конфликта. Но вот та откровенная дезинформация, что льется с лент информагенств — добивание грузинами пленных и раненных, тысячи погибших, ковровые бомбежки — это полный финиш. Непонятно каким идиотом нужно быть, что бы верить. И если телевидению уже не привыкать пачкаться, то для некоторых Интернет СМИ это будет в первый раз. Хорошо, что в сети есть свобода выбора, убираю из RSS ридера made in говнораша новости.

Рубрики: Мысли | Комментариев нет »

К событиям в Грузии

08.08.2008 от vvd

Вспомнил про игрушку Ghost Recon, она вышла 7 лет назад, но создатели удивительно точно угадали год и сюжет конфликта. Действие начинает развиваться как раз в 2008 году на территории оккупированной российскими войсками Грузии.

Рубрики: Новости | Комментариев нет »