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

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

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

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

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

Напомним типовую схему поиска IP-адреса по доменному имени.

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

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

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

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

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

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

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

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

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

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

С приемлемостью времени загрузки до 5 секунд согласны и «художники» баннеров, рекомендуя стандартный размер баннера в 10-15 Кбайт [12]: именно столько удается передать при коммутируемом соединении со скоростью 28,8 кбит/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 начинает опрос второго сервера, первый сервер все равно пытается выполнить запрос (получить ответ и кэшировать его), поэтому при повторном обращении к нему он может иметь уже в своем распоряжении нужный ответ.

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

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

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

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

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

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

Более точные измерения проведены в работе [16]. Если в CIADA измерялось RTT от серверов к опрашивающим их хостам, то здесь использовалась программа, которая, будучи установленной в различных точках Сети и измеряла непосредственно отклик корневых серверов и серверов национальных доменов. Согласно данным [16], для США и Европы характерным временем отклика является время, меньшее 0,2 с. Здесь следует сделать оговорку. Основной объем трафика DNS приходится на корневой A-сервер; поэтому именно время отклика этого сервера и является определяющим, а оно при прямом подключении в редких случаях превышает 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).

Согласно статистике 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 (два порядка величины) выглядят на этом фоне, мягко говоря, странно.

Следует учитывать тот факт, что серверы, поддерживающие домены второго уровня в зоне 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 предполагают «одинаковость» авторитативных серверов доменов.

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

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

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

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

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

У ИТ-общественности еще нет четкого понимания того, чем конкретно (убытки, потерянные пользователи, четко измеренные недопустимые задержки и т.п.) может грозить неправильное размещение DNS-сервера. Для Рунета никто не рассчитывал времена отклика на запрос ресурсов, не изучал составляющие времени отклика, и влияние всего этого на бизнес. Между тем, к примеру, при изменении маршрутизации в конце прошлого года тремя ведущими российскими провайдерами и увеличении RTT некоторые бизнесмены от Internet потеряли пользователей и, соответственно, понесли убытки, но их измерений и корреляций никто не делал. На Западе работы, посвященные измерению RTT тем же методом, что и рассмотренные в данной статье, были проведены в конце прошлого года [18]. Предполагается, что это поможет судить о влиянии RTT на эффективность работы Сети, однако пока эти работы еще не завершены. В общем случае, это достаточно серьезная проблема, затрагивающая оценку всего объема трафика, предоставляемого отечественными провайдерами.

Литература

1. Uniform Resource Identifiers (URI): Generic Syntax. RFC-2396, 1998 (http://www.ietf.org/rfc/rfc2396.txt?number=2396)
2. Role of the Domain Name System (DNS). RFC-3467.2003 (http://www.ietf.org/rfc/rfc3467.txt?number=3467)
3. P. Mockapetris. Domain Names - Concepts and Facilities. RFC-1034, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
4. P. Mockapetris. Domain Names - Implementation and Specification. RFC-1035. 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
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. ФОН. (http://www.fom.ru/reports/frames/o0316061.html)
7. Аудитория Рунета по методике SpyLOG-монитор. 2003. Апрель. (http://gs.spylog.ru/interesting.phtml?id=53&PHPSESSID=817c3cea3231167985d03a45df37d2dc)
8. Selection and Operation of Secondary DNS Servers. RFC-2182. 1997. (http://www.ietf.org/rfc/rfc2182.txt?number=2182)
9. Регламент регистрации доменов в домене RU. 19.08.2002. (http://www.nic.ru/dns/contract/sup1_1_ru.html)
10. Bob Bailey. Acceptable Computer Response Times. UI Design Update Newsletter - April, 2001. (http://www.humanfactors.com/downloads/apr012.htm)
11. Bob Bailey. Improving User Performance. UI Design Update Newsletter - June, 2000. (http://www.humanfactors.com/downloads/june00.asp)
12. Тимофей Бокарев. Энциклопедия Интернет-рекламы. (http://book.promo.ru/book/)
13. Unix Manual Page for resolv.conf. (http://www.scit.wlv.ac.uk/cgi-bin/mansec?4+resolv.conf)
14. The dig Manual Page. (http://www.stopspam.org/usenet/mmf/man/dig.html)
15. Ryuji Somegawa, Kenjiro Cho, Yuji Sekiya, Suguru Yamaguchi. The Effects of Server Placement and Server Selection for Internet Services. IEICE Trans. Commun. Vol. E86-B, No. 2, February 2003.
16. 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. (http://moat.nlanr.net/PAM2003/PAM2003papers/3794.pdf)
17. Статистика регистрации и делегирования доменов в зоне RU на 2003-06-16 (http://stat.nic.ru/2003/06/16/stats-20030616.shtml)
18. 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)