Как правильно разместить DNS-сервер

Павел Храмцов
Журнал «Открытые Системы», #9/2003

Среди ИТ-специалистов все более популярным сегодня становится вопрос разработки систем распространения контента (content distribution system), на успех работы которых очень влияет размещение информационных серверов. Речь идет о таком размещении серверов, при котором время доступа было бы если не минимальным, то хотя бы приемлемым (отвечающим SLA). Фактически, требуется в единицу времени обслужить максимальное число пользователей при заданном времени обслуживания одного. Например, для Web-страниц таким ограничивающим фактором будет приемлемое время загрузки страницы браузером, которое складывается не только из времени передачи данных по сети и времени их интерпретации, но также и времени, затраченного на поиск IP-адреса сервера в том числе и из времени обращения к сервису Системы Доменных Имен (DNS).

Мой адрес не дом и не улица…

Система доменных имен Internet – ключевой сервис, на который в сети замыкаются адреса информационных ресурсов, а точнее их идентификаторы (Uniform Resource Identifier, URI, RFC-2396 [1]). Как отмечено в RFC-3467 [2], посвященном роли системы доменных имен, архитектура DNS оставалась неизменной с момента своего создания, в то время как ее функции существенно изменились -- коммерциализация Сети привела к существенному «уплощению» иерархии доменных имен. Владельцы сервисов предпочитают использовать домены 2-ого уровня в рамках национальных доменов или доменов общего назначения, например microsoft.com, а не закапываться вглубь иерархии имен. Кроме того, начиная с 90-х годов, систему DNS стали использовать в качестве инструмента балансировки нагрузки серверов информационных ресурсов, эксплуатируя для этого алгоритм Round Robin, который применяется серверами доменных имен при ответе на запросы клиентов. Ни первое, ни второе при проектировании системы доменных имен не предполагалось. Во всяком случае, в основополагающих документах RFC-1034 [3] и RFC-1035 [4] этого не указано.

Вспомним типовую схему поиска IP-адреса по доменному имени (рис.1)

Рис.1. Схема получения IP-адреса по известному доменному имени в системе DNS

Браузер через механизм resolver обращается к локальному кэширующему серверу доменных имен с рекурсивным запросом. Этому серверу передается доменное имя, для которого нужно найти IP-адрес. Сам браузер IP-адрес не ищет, а перепоручает это локальному кэширующему серверу доменных имен (в этом может убедиться каждый, кто сам настраивал подключение своего компьютера к Сети). При подключении через провайдера, например, по коммутируемому соединению, этого делать не нужно: сеть настраивается в большинстве случаев автоматически (в момент автоматической настройки провайдер по протоколу PPP присылает IP-адреса серверов доменных имен, которые будут выполнять рекурсивные запросы пользователя).

На схеме (Рис. 1) указаны два типа запросов: рекурсивный и нерекурсивный. Первый – это запрос, при котором клиент перепоручает поиск IP-адреса серверу, второй – запрос при котором клиент сам производит опрос серверов. Локальный кэширующий сервер самостоятельно опрашивает все серверы доменных имен, поэтому он обменивается с ними нерекурсивными запросами.

В системе доменных имен существует жесткая иерархия имен. Начинается она с корня, который часто обозначают как «.», хотя это и не совсем правильно. Затем следуют домены верхнего уровня (Top Level Domains, TLD), например, com., org., net., ru. и т.п. Далее следуют домены второго уровня, например, nic.ru, vesti.ru и т.п. Каждый домен поддерживается авторитарным сервером домена и, как правило, не одним. При этом сервер, который поддерживает старшие имена, имеет возможность перепоручить управление младшими именами другому серверу. Такое перепоручение отражается в описании домена, управляемом сервером, и называется делегированием. Та часть дерева иерархи имен, которой управляет сервер, называется зоной. Если серверу поручено управлять корнем дерева имен, и он перепоручил все TLD другим серверам, то в его ведении остается только управление соответствиями между именами доменов и именами серверов, которым он эти домены перепоручил.

Кому поручено управления младшими именами, знает только тот сервер, который осуществляет делегирование, поэтому, когда мы ищем что-то в домене RU, мы сначала должны узнать, кто поддерживает домен RU, а потом, кто поддерживает ту часть домена RU, которая, собственно, нас и интересует. На первый вопрос отвечает корневой сервер, который обслуживает «корень» имен DNS – корневую зону. Таких серверов 13 -- 10 в США, 2 в Европе и один в Японии. До сих пор такое размещение было оправдано (согласно данным CIADA (Cooperative Association for Internet Data Analysis) [5] около 60% клиентов корневых серверов размещены в США). На второй вопрос ответят серверы, поддерживающие национальный домен RU. Их шесть: три размещены в России и три в Европе. Кстати, если верить статистике Фонда «Общественное мнение» [6], то 19% пользователей Рунета находятся в Москве, там же, где расположены и три российских сервера зоны RU. С точки зрения использования DNS, правильнее ориентироваться на данные SpyLog, которые получены на основе агрегирования статистики его счетчиков, размещенных на Web-сайтах -- на апрель 2003 года в Москве находилось 43% всех городских пользователей Рунета [7].

После получения ответа с сервера, поддерживающего национальный домен, мы можем обратиться к авторитативному (authorative) серверу домена, которому принадлежит интересующее нас имя. Авторитативным этот сервер называют по той причине, что именно ему делегировано право отвечать на запросы к именам из этого домена. По правилам делегирования доменов второго уровня в RU для каждого домена таких серверов должно быть не менее двух. Вообще говоря, их может быть и больше -- RFC-2182 [8] рекомендует иметь три. Нарушением регламента регистрации доменов, способным повлечь временную приостановку делегирования, является ситуация когда, суммарное время отсутствия связи с сервером превышает два часа за сутки [9]. Ели домен обеспечен тремя серверами, то вероятность отказа сразу на двух серверах меньше, чем на одном, что существенно понижает риск временной потери делегирования. На самом деле, локальный кэширующий сервер доменных имен обращается к корневым серверам и авторитативным серверам домена RU только тогда, когда не может найти необходимый ему адрес в своем кэше.

Время хранения соответствий в кэше сервера определяется временем TTL (Time To Live), которое устанавливает администратор соответствующего домена. Например, TTL имен авторитативных серверов домена RU равно 86400 секунд или 1 сутки, т.е. после первого обращения за адресом из домена RU локальный кэширующий сервер доменных имен обратиться к корневому серверу за получением списка авторитативных серверов домена RU только через сутки. Аналогичная схема работает и для всех остальных доменов. Если один пользователь обратился, например, к www.yandex.ru через локальный кэширующий сервер dialup провайдера, то этот сервер будет обслуживать всех остальных пользователей этого провайдера в течение суток, не обращаясь ни к корневым серверам доменных имен, ни к авторитативным серверам домена RU. Но, если в качестве примера выбрать www.rambler.ru, то такое кэширование (по данным на июнь 2003 года) будет осуществляться только 1 час. А для mail.ru это время будет равно двум часам. Таким образом, для конкретного пользователя системы DNS время отклика будет варьироваться от времени полного опроса всех серверов, обслуживающих искомый адрес, начиная от корневого сервера и кончая авторитативным сервером поддомена, до времени опроса только своего локального кэширующего сервера.

Вернемся к вопросу о времени отклика на запрос, а точнее к RTT (Round Trip Time), которое обычно и используют в качестве основы различных метрик в расчетах эффективности размещения сервисов [5].

Не думай о секундах с высока…

Итак, мы хотим добиться приемлемого для пользователя времени обработки запроса, однако, прежде разберемся чему может быть равно это время.

Как показывают исследования [10, 11], все зависит от того, какую задачу решает пользователь. При этом обычно исследуют либо время задержки, которое начинает вызывать раздражение, либо влияние времени задержки на эффективность работы в целом. Обычно время задержки (загрузки Web-страницы) свыше 1 с., вызывает дискомфорт, однако, если пользователь знает, что он получит, то раздражения не вызывают и задержки до 5 секунд. Но после 30 с. речь уже не может идти об интерактивной работе. В целом для работы с известным интерфейсом подходит следующая шкала: до 5 секунд – «хорошо»; до 10 секунд – «удовлетворительно»; более 10 секунд – «плохо». Однако, если показывать элементы страницы по мере их получения, то шкала для времени полной загрузки страницы изменится: до 39 с. – «хорошо»; до 56 с. – «удовлетворительно»; более 56 секунд – «плохо». Любопытно и другое -- непреодолимое желание «ускорить» процесс возникает в среднем после 8,6 секунд ожидания хоть какого-нибудь результата.

С приемлемостью времени загрузки до 5 секунд согласны и «художники» баннеров, рекомендуя стандартный размер баннера в 10-15 Кбайт [12] – именно столько удается передать при dialup-соединении со скоростью 28800 бит/c за 3 – 5 с. На самом деле не стоит надеяться, что зашедший первый раз на ваш сайт пользователь будет ждать 5 секунд, а уж баннеры большинство пользователей однозначно не любят, поэтому при разработке страниц стоит все-таки стремиться к односекундной задержке до появления первого символа на экране.

Заметим, однако, что, во-первых, баннер – это только часть страницы, во-вторых, для него, как правило, необходим отдельный поиск IP-адреса. Баннерообменные системы располагаются не в том же самом месте, где и сам сайт. Кроме того, нужно время на загрузку иллюстраций. Одним словом, время, затраченное на поиск IP-адресов – это только часть времени загрузки, которое должно быть существенно меньше, чем приемлемое время загрузки страницы. А на сколько меньше -- это определяется техническими ограничениями и реализацией алгоритма поиска в системе DNS.

Попытка - не пытка…

Фактически, алгоритм поиска IP-адреса по имени – это многоступенчатый процесс, состоящий из серий попыток, которые выполняет "решатель" resolver и локальный кэширующий сервер (рис.1). У каждого из них примерно одинаковый механизм опроса серверов доменных имен за исключением того, что кэширующий сервер применяет ранжирование авторитативных серверов зон по RTT. Рассмотри этот алгоритм более внимательно.

В настройках resolver обычно указывают один-два сервера доменных имен, к которым он обращается с рекурсивными запросами. Процесс опроса начинается с первого сервера в списке и идет последовательно. Может быть совершено до четырех попыток. В первой попытке resolver ждет отклика от сервера 5 секунд, после чего переходит к следующему серверу. Если ответ не получен, то период ожидания увеличивается вдвое, и опрос серверов возобновляется с первого сервера в списке. Если resolver использует только один сервер, то тогда максимальное время ожидания отклика равно 75с (5+10+20+40). Если серверов несколько, то возможно два варианта. В первом приведенный алгоритм справедлив для каждого сервера [13], во втором время ожидания при каждой попытке на каждом сервере получается как результат деления установленного для данной попытки времени ожидания на число серверов. Например, для первой попытки и случая двух серверов оно будет равно 5/2 [14].

Следует пояснить, почему время суммируется. При рекурсивном запросе resolver перепоручает нахождение адреса локальному кэширующему серверу. Даже когда resolver начинает опрос второго сервера, первый сервер все равно пытается выполнить запрос (получить ответ и его закэшировать), поэтому при повторном обращении к нему он может уже иметь в своем распоряжении нужный ответ.

Теперь перейдем ко второму звену поиска адреса – локальному кэширующему серверу. Он точно также опрашивает сервера, только их список он получает не из файла на диске, а из ответов других серверов. В нашем случае, когда мы не углубляемся в иерархию доменных имен дальше доменов второго уровня, список авторитативных серверов зоны домена 2-ого уровня он получает от авторитативного сервера зоны RU. Список авторитативных серверов зоны RU он, в свою очередь, получает от корневого сервера, а список корневых серверов из своего файла настройки. Время кэширования списка авторитативных серверов зоны RU – одни сутки, поэтому основной вклад во время поиска будет вносить время доступа к авторитативным серверам искомой зоны домена второго уровня.

На самом деле различные серверы применяют различный алгоритм выбора первого сервера для опроса [15] -- BIND ранжирует серверы по RTT, а Windows выбирает просто случайным образом из полученного списка.

Что же дает анализ работы resolver в плане понимания компонентов времени отклика при поиске адреса? Во-первых, первым в настройках resolver должен быть указан сервер, который быстрее всего откликается на запросы клиента, т.е. локальный кэширующий сервер должен быть расположен как можно ближе к пользователю. Во-вторых, все серверы зоны должны быть одинаково хорошо расположены относительно пользователя, точнее его кэширующего сервера, т.к. не факт, что клиент Windows, например, запросит тот сервер, который лучше всего расположен относительно него. В-третьих, с точки зрения «человеческого фактора» время задержки в 5 секунд достаточно большое для того, чтобы браузер пользователя многократно обращался к серверам.

Что такое хорошо, и что такое плохо…

Какое время отклика DNS сервера принято считать «хорошим», а какое «плохим»? Посмотрим при этом на наиболее загруженные и критичные с точки зрения всей системы серверы – корневые и те, что обслуживают «национальные» домены.

За последние два года было проведена ряд исследований в этой области. Специалисты CIADA[5] изучали время отклика корневых серверов на запросы клиентов со всего земного шара. Время отклика признавалось большим, если превышало 90% точку распределения времени отклика. Типичным большим временем отклика в этом исследовании было время большее 0,5 с. Следует заметить, что для России из 437 точек только 14 имели большое время отклика (3% от общего числа российских участников), что сравнимо с данными по Бразилии. Важно также, что за полгода пока проводились эти исследования доля точек в России с большим откликом не изменилась (например, на Украине она увеличилась в два раза) и была отмечена общая тенденция к сокращению времени отклика.

Более точные измерения проведены работе [16]. Если в CIADA измерялось RTT от серверов к опрашивающим их хостам, то здесь использовалась программа, которая, будучи установленной в различных точках Сети и измеряла непосредственно отклик корневых серверов и серверов национальных доменов. Согласно данным [16] для США и Европы характерным временем отклика является время меньше 0,2 с. Здесь следует оговориться. В силу различных причин, основной объем DNS трафика приходится на корневой A-сервер, поэтому именно время отклика от этого сервера и является определяющим, а оно при прямом подключении (исследовался также и dialup) в редких случаях превышает 0,2 с. Как правило, время отклика ccTLD серверов несколько хуже, чем корневых -- порядка нескольких десятых долей секунды. Например, для Парижа среднее время отклика A-сервера равно 0,18 с, а сервера национального домена FR – примерно, 0,25 с.

В этой связи интересно посмотреть, а какое время отклика имеют серверы, поддерживающие домены в зоне RU? Для этого было решено замерять время обращения за SOA (Start Of Authority) записью зоны, для которой сервер является авторитативным, проверять авторитативность отклика и запоминать RTT отклика. Измерения проводились из точки, для которой значение RTT до ns.ripn.net было равно 0,0013 с (запрос SOA для зоны RU), т.е. фактически от авторитативного сервера зоны RU. Полученное распределение приведено на рис.2.

Рис.2. Распределение времени отклика серверов доменов второго уровня в зоне RU

Cогласно статистике компании RU-CENTER, на момент проведения измерений в зоне RU было 28106 серверов [17], которые поддерживали домены второго уровня. Это означает, что 48% серверов имели время отклика менее 0,1 секунды. Еще 12% попадали в интервал от 0,1-0,2 с. Приемлемое время отклика до 1 секунды имело 79% серверов и до 5 с укладывался 81% серверов.

Интересно посмотреть на 10 самых медленных (Таблица 1) и самых быстрых (Таблица 2)серверов из 50 наиболее популярных (по числу поддерживаемых ими уникальных доменов в зоне RU).

Разница между самыми быстрыми и самыми медленными наиболее популярными серверами составляет в среднем порядок. Пять с слишком секунд для ns1.masterhost.ru (2 порядка величины) выглядят на этом фоне, мягко говоря, странно.

Следует учитывать тот факт, что серверы, поддерживающие домены второго уровня в зоне RU, как и во всем мире [18], в большинстве случаев (70%) одновременно являются и серверами, которые выполняют рекурсивные запросы. Чем ближе данный сервер расположен к корневому серверу, тем лучше и тем больше времени из интервала «приемлемого времени» останется на передачу полезной информации, а не на накладные расходы, которыми является сервис DNS.

Конечно, можно возразить, что важно не как близко ты находишься к корню, а как близко к своим клиентам, т.к. время отклика кэшируется, и не за каждым адресом приходится лазить на авторитативный сервер доменных имен. Но больше половины пользователей, собственно, и находятся около авторитативных серверов зоны RU, что показывает распределение времени отклика серверов доменов второго уровня.

Есть еще один момент. Например, rambler.ru, как уже было указано, кэшируется только час, а время доступа до него от ns.ripn.net 0,004 с. Для mail.ru время доступа от ns.ripn.ru тоже 0,004 с. Время определяется не только физическим расстоянием, но и качеством, и пропускной способностью канала. Например, для сервера ns.nsk.ru время отклика составляет 0,18 с, а для ns.spb.su – 0,019 с. В таких условиях времена отклика серверов доменных имен хостинг-провайдеров, которые превышают 0,15 секунды выглядят плохо. Понятно, что это, скорее всего дулирующие серверы (secondary), но алгоритмы выбора серверов resolver предполагают «одинаковость» авторитативных серверов доменов.

Сухой остаток

Следует признать «приемлемым» время загрузки от 1 до 5 с, а в качестве цели, которую желательно достичь при разработке страниц сайтов – 1 с до появления первого символа на экране пользователя.

Таблица 1 Десять самых медленных серверов

Таблица 2. Десять самых быстрых из 50-и наиболее популярных

В качестве цели при размещении DNS серверов следует признать такое время поиска в системе DNS, которое не превышало бы 0,15 с. Согласно измерениям времени отклика серверов доменных имен второго уровня в зоне RU, более половины серверов удовлетворяют этим условиям.

Для надежного обеспечения поиска своих ресурсов в сети следует не ограничиваться двумя авторитативными серверами, а увеличить их число до трех, чтобы не оказаться в ситуации приостановки делегирования.

«Хорошо» размещать нужно не только primary (master) сервер зоны, но и все авторитативные серверы -- неисправность любого из них грозит приостановкой делегирования, а кроме того, совершенно не обязательно, что resolver-сервер пользователя выберет при поиске primary сервер.

Литература

1. Uniform Resource Identifiers (URI): Generic Syntax. RFC-2396, 1998 ()
2. Role of the Domain Name System (DNS). RFC-3467.2003
3. P. Mockapetris. DOMAIN NAMES - CONCEPTS AND FACILITIES. RFC-1034, 1987.
4. P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. RFC-1035. 1987.
5. Marina Fomenkov, kc claffy, Bradley Huffaker, David Moore. Macroscopic Internet Topology and Performance Measurements From the DNS Root Name Servers. 2001 LISA XV – December 2-7, 2001 –San Diego, CA.
6. Галицкий Е.Б. Опросы "Интернет в России". Выпуск 3. Весна 2003. ФОН.
7. Аудитория Рунета по методике SpyLOG-монитор. Апрель 2003.
8. Selection and Operation of Secondary DNS Servers. RFC-2182. 1997. ()
9. Регламент регистрации доменов в домене RU. 19.08.2002.
10. Bob Bailey. Acceptable Computer Response Times. UI Design Update Newsletter – April, 2001.
11. Bob Bailey. Improving User Performance. UI Design Update Newsletter – June, 2000.
12. Тимофей Бокарев. Энциклопедия Интернет-рекламы.
13. Unix Manual Page for resolv.conf. The dig Manual Page.
14. Ryuji SOMEGAWA, KenjiroCHO, Yuji SEKIYA, Suguru YAMAGUCHI. The Effects of Server Placement and Server Selection for Internet Services. IEICE TRANS. COMMUN. VOL.E86-B, NO.2 FENRUARY 2003.
15. Yuji Sekiya, Kenjiro Cho, Ryuji Somagawa, Tatsuya Jinmei, Jun Murai. Root and ccTLD DNS server observation from worldwide locations. PAM2003. La Jolla, CA, April 6-8 2003.
16. Статистика регистрации и делегирования доменов в зоне RU на 2003-06-16
17. Krishna P. Gummadi, Stefan Saroiu, Steven D.Gribble. King: Estimating Latency between Arbitrary Internet End Hosts. IMW 2002. November 6-8, 2002. (http://www.icir.org/vern/imw-2002/imw2002-papers/198.pdf)