Система доменных имен

Материалы книги П.Б. Храмцова
iнфоцентр

Запись "Name Server"(NS), проблема некорректного делегирования зон (lame delegation), метрика RTT (round trip time) и ее применение в BIND

Здесь мы обсуждаем вопросы применения записи описания ресурсов NS (Name Server). Подробно разбираем вопрос некорректного делегирования зон, а также алгоритм выбора наиболее подходящего авторитативного сервера для обслуживания запросов к зоне.

Запись NS используется для обозначения сервера, который поддерживает описание зоны. Собственно, когда resolver обращается к системе доменных имен за IP-адресом или доменным именем, то, скорее всего, он получит для начала NS-запись, которая будет указывать на сервер доменных имен, который знает где можно получить необходимую информацию. Именно этот отклик и называют рефералом или отсылкой.

Кроме того, запись NS позволяет делегировать поддомены, поддерживая тем самым иерархию доменов системы доменных имен Internet. Для того, чтобы домен был виден в сети в зоне описания домена старшего уровня должна быть указана запись типа NS для этого поддомена. Формат записи NS можно записать в виде:

[domain][ttl] IN NS [server]

В поле domain указывается имя домена, для которого сервер, указанный последним аргументом записи NS, поддерживает описание зоны. Значение поля ttl обычно оставляют пустым, тем самым, заставляя named устанавливать значение по умолчанию (поле minimum из записи SOA для данной зоны в старых версиях BIND или значение директивы управления $TTL).

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

Записи NS указывают как на master, так и на slave серверы. Последние, обычно, принадлежат другим зонам, и для них следует указывать полное доменное имя сервера с указанием имени машины и имени зоны. Например, для сервера из домена polyn.kiae.su c именем ns следует писать полностью ns.polyn.kiae.su. Для того чтобы придерживаться какого-то единого стиля и во избежание ошибок, рекомендуется писать всегда полное имя сервера.

Какой либо разницы между master и slave в NS не указывается. Обычно primary master записывают первым, а резервные серверы указывают вслед за ним.

Приведем пример записи описывающей сервер доменных имен для поддомена:

$ORIGIN vega.ru.
zone1		IN	NS	ns.zone1.vega.ru.

В данном примере в качестве первой строки используется команда $ORIGIN, которая определяет имя текущей зоны (см. материал "Файлы описания зоны. Директивы управления"). Здесь она введена только для того, чтобы определить текущую зону.

В поле имени зоны указано имя zone1 без точки на конце. В данном контексте это означает делегирование зоны в домене vega.ru, полное имя которой будет zone1.vega.ru.

В качестве имени сервера, который управляет делегированной зоной указано имя ns.zone1.vega.ru, т.е. полное имя машины в делегированном домене. В принципе, в данном случае можно было бы написать и по другому:

$ORIGIN vega.ru.
zone1		IN	NS	ns.zone1

т.к. имя принадлежит текущему домену и может быть расширено его именем.

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

Длина метки узла дерева доменных имен должна находится в пределах от 1 до 63 октетов (RFC 2181). Любопытно, что написано не "символов", а октетов, то бишь байтов.

При этом длина полного имени (Full Qualified Doman Name -FQDN) не должна превышать 255 октетов, включая разделители ( те самые символы ".", которые ставятся между именами меток узлов). Полное имя узла - это имя от узла до корня дерева доменных имен.

Таким образом, максимальное имя корпоративного домена в зоне ru (что-то типа "corporative-name.ru") не может быть больше 63 символов, а вместе с двумя точками и "ru" не должно превышать 67 символов.

Теперь вернемся к NS записям. NS-записи обычно следуют сразу за записью SOA в файле описания зоны и указывают на серверы, которые ответственны за эту зону:

$ORIGIN ru.
Webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. (
                          1 3600 600 86400 3600 )
        3600    IN      NS      ns.webstatistics.ru.
        3600    IN      NS      ns4.nic.ru.

В данном случае описана зона webstatistics.ru и для нее вслед за SOA указано два сервера доменных имен: ns.webstatistics.ru - primary master и ns4.nic.ru - slave.

Такого простого указания на серверы доменных имен зоны для нормальной работы недостаточно. Нужно еще знать IP-адреса этих серверов. Для slave его можно найти в зоне nic.ru, а вот для ns.webstatistics.ru нужно использовать "приклеенную" адресную запись (см. подробнее материал "Адресная запись "Address". Балансировка нагрузки. Round Robin. Учет топологии сетей.").

Рассмотрим еще одну причину использования NS-записей в описаниях зон - делегирование зоны.

До сих пор мы рассматривали NS запись только для объявления сервера доменных имен для той зоны, которую описываем, например, zone.ru:

@	IN	SOA	ns.zone.ru. hostmaster.zone.ru. (
			2002092602 1d 3h 4w 3h )
	IN	NS	ns.zone.ru.
	IN	NS	ns.provider.ru.

Но это только часть функций NS записи. Теперь делегируем право ответственности за часть зоны другому администратору и выделяем в домене zone.ru зону subzone1. Этот факт мы должны отобразить в описании зоны zone.ru:

@	IN	SOA	ns.zone.ru. hostmaster.zone.ru. (
			2002092602 1d 3h 4w 3h )
		IN	NS	ns.zone.ru.
		IN	NS	ns.provider.ru.
ns		IN	A	192.168.0.1
;
subzone1	IN	NS	ns.subzone1.zone.ru.
		IN	NS	ns.zone.ru.
ns.subzone1	IN	A	192.168.1.1

В данном случае имя subzone1 будет расширено именем текущей зоны (zone.ru), т.к. оно не завершается символом ".", а текущим является zone.ru, которое берется из файла конфигурации named потому, что указан символ "@" в записи SOA описания зоны.

На то, что subzone1 - это имя поддомена, указывает запись NS, потому, как у нее первое поле принимает значение имени домена (зоны).

При этом для зоны subzone1.zone.ru определено два авторитативных сервера: ns.subzone1.zone.ru и ns.zone.ru. Теперь, если к нашему серверу обратятся за адресом хоста из subzone1.zone.ru, то отошлем их к другим серверам, которые ответственны за эту зону.

Фраза "отошлем к другим серверам" означает то, что наш сервер вернет запрашивающему его клиенту или серверу, который выполняет рекурсивный запрос, имена и, если в зоне они прописаны, IP-адреса серверов доменных имен, ответственных за зону, где находится хост с заданным клиентом именем или адресом.

Понятно, что кроме нас адреса сервера домена, расположенного ниже в иерархии доменных имен, чем наш домен, никто не знает, поэтому в нашей зоне и содержится "приклеенная" адресная запись для соответствующего сервера:

ns.subzone1	IN	A	192.168.1.1

Если внимательно присмотреться к описанию этого примера, то становится ясно, что наш сервер никуда никого отправлять не будет, т.к. он сам является авторитативным для зоны subzone1.zone.ru. Скорее всего, он является slave-ом, а ns.subzone1.zone.ru - это master.

Просто мы имеем еще один файл описания зоны, который копируем с ns.subzone1.zone.ru, и где находится описание зоны subzone1.zone.ru.

Подобная ситуация довольно типична, если клиенты провайдера используют его же сервер доменных имен в качестве slave, или если внутри организации происходит делегирование зон отдельным подразделениям. В первом случае выполняется условие независимого подключения, а во втором, т.к. домен находится ниже второго (корпоративного уровня), требования независимого подключения соблюдать хоть и желательно, но вовсе необязательно.

Теперь, когда понятна процедура делегирования зоны, вернемся к NS записям, описывающим серверы нашей зоны в нашем же описании зоны, а не там, где нам эту зону (нашу зону) делегировали.

С нашим сервером проблем не возникает. Мы сами его администрируем. А вот с администраторами серверов, которые (серверы) мы прописываем в зоне в качестве авторитативных, следует сначала договориться. Не нужно прописывать имена серверов "от балды". Эти серверы должны быть действительно slave для вашей зоны. Как правило, при регистрации домена проверяются все серверы, указанные в заявке.

Вообще говоря, по идее, неправильное указание имени сервера авторитативного за зону внутри описания самой этой зоны не должно влиять на работу других серверов. BIND не проверяет соответствие серверов в родительской зоне и в зоне-потомке. Другое дело неправильное делегирование (lame delegation), когда сервер родительской зоны перенаправляет клиента к серверу, который не является авторитативным для зоны-потомка.

В нашем случае, например, сервер ns.zone.ru может быть не настроен в качестве slave для зоны subzone1.zone.ru. Тогда ряд запросов может быть отвергнут, что, конечно, плохо.

Еще раз подитожим, что под некорректным делегированием понимают:

• наличие NS-записи, в которой указано имя сервера доменных имен, чей адрес невозможно найти;
• наличие NS-записи, в которой указано имя сервера доменных имен, не отвечающего на запросы;
• наличие NS-записи, в которой указано имя сервера доменных имен, негативно отвечающего на запросы.

На самом деле проблема некорректного делегирования достаточно серьезна. Так, например, Men&Mice в августе 2002 провела исследование 5000 случайно выбранных доменов в зоне com. Некорректное делегирование зоны было выявлено в 20% случаев. Это на один процент лучше, чем было в мае 2002 года, но все равно достаточно много. Любопытно, что в 14% случаев информация о делегировании зоны не совпадала с данными, указанными в самой зоне, а 17% случаев не удалось найти авторитативных серверов зоны.

Вообще говоря, проблема некорректного делегирования имеет решение, если сервер родительской зоны поддерживает механизм зон-заглушек (stub zone). Этот реализован в современных версиях BIND. Он позволяет серверу родительской зоны отслеживать изменения NS-записей делегированной зоны.

Для создания stub зоны следует в файл конфигурации named добавить:

zone "webstatistics.ru" {
	type stub;
	file "webstatistics.ru";
	masters {144.206.192.60;};
}

В этом случае сервер, на котором организована stub зона будет срисовывать в соответствующий файл запись SOA и NS-записи описания зоны.

Пусть описание зоны будет иметь вид:

$ORIGIN ru.
Webstatistics 3600 IN SOA webstatistics.ru. paul.webstatistics.ru. (
                1 3600 600 86400 3600 )
        3600    IN      NS      ns.webstatistics.ru.
        3600    IN      NS      ns4.nic.ru.
                IN      A       144.206.192.60
$ORIGIN webstatistics.ru.
ns      3600    IN      A       144.206.192.60
$ORIGIN nic.ru.
ns4             IN      A       194.226.96.8
$ORIGIN webstatistics.ru.
www     3       IN      A       144.206.192.60
        3       IN      A       144.206.192.61
        3       IN      A       144.206.192.62
        3       IN      A       144.206.160.32

Содержание файла типа stub на для зоны webstatistics.ru будет иметь следующий вид:

; BIND version named 8.2.2-P5-NOESW Mon Mar 20 20:39:05 GMT 2000
; BIND version root@monster.cdrom.com:/usr/obj/usr/src/libexec/named-xfer
; zone 'webstatistics.ru'   first transfer
; from 144.206.192.60:53 (local 144.206.160.32) using AXFR at Mon Oct 7 19:31:1
; 7 2002
$ORIGIN ru.
Webstatistics 3600 IN SOA ns.webstatistics.ru. paul.webstatistics.ru. (
                1 3600 600 86400 3600 )
        3600    IN      NS      ns.webstatistics.ru.
        3600    IN      NS      ns4.nic.ru.
$ORIGIN webstatistics.ru.
ns      3600    IN      A       144.206.192.60
; Ignoring info about ns4.nic.ru, not in zone webstatistics.ru.
; $ORIGIN nic.ru.
; ns4   60575   IN      A       194.226.96.8

Из этого примера хорошо видно, что в зону были скопированы записи SOA, NS и "приклеенные" адресные записи. При этом адресная запись для slave сервера была проигнорирована, т.к. она принадлежит другой зоне и в ней нет необходимости (подробнее см. материал "Адресная запись "Address". Балансировка нагрузки. Round Robin. Учет топологии сетей.").

На самом деле есть одна загвоздка, которая делает указанный выше метод не достаточно удобным. Дело в том, что серийный номер родительской зоны не изменяется и, следовательно, slave-ы родительской зоны об изменениях в делегировании ничего знать не будут, если на них не настроить поддержку stub зоны.

В документации по BIND версии 9 не рекомендовано использовать зоны-заглушки для вновь создаваемых зон. Разработчики BIND советуют просто строго следовать правилам делегирования зоны.

При делегировании зоны нужно четко отдавать себе отчет в том, что администраторы делегированного домена не обязаны сообщать нам адрес primary master, т.е. того сервера, на котором происходит реальное редактирование информации о зоне. Они (администраторы) могут просто сообщить нам адреса своих slave серверов, которые тоже являются авторитативными для зоны. В этом случае мы будем иметь невидимый primary master сервер. Делается это, главным образом, из соображений безопасности.

На самом деле, остался не выясненным еще один вопрос, который тесно увязан с авторитативными серверами доменных имен. Это вопрос о порядке их опроса локальным сервером доменных имен, который выполняет рекурсивный запрос resolver-а.

На самом деле все достаточно просто. Когда сервер получает рекурсивный запрос, и в итоге опроса серверов доменных имен в конце концов получает список авторитативных серверов требуемой зоны, он для каждого из них включает метрику RRT (round trip time). Эта метрика в миллисекундах измеряет время отклика от каждого из серверов. В начальный момент времени, т.е. при первом запросе, она устанавливается в 0.

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

Наиболее эффективен этот алгоритм при работе с корневыми серверами,т.к. к ним приходится обращаться постоянно.

Следует заметить, что серверы, отличные от BIND могу реализовывать другие алгоритмы выбора сервера, т.к. в спецификации DNS этот вопрос не прояснен.

Любопытно, что измерения RTT для корневых серверов проведенные в 2000 году, хорошо совпали с RTT команды ping. Не обобщая этот вывод на все случаи жизни, тем не менее можно сказать, что доступность DNS сервера можно оценивать по скорости отклика ping.

Вообще говоря, описанный алгоритм выбора аторитативного сервера на основе RTT не догма и его эффективность постоянно подвергается оценке. Основной вопрос, на который хотят получить ответ службы поддержки корневых серверов- это почему основная нагрузка падает на A сервер, в то время как ближайший к нему M сервер имеет нагрузку почти на четверть меньшую.

Рекомендованная литература:

1. P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
2. P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
3. Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
4. Документация по BIND 9. Справочное руководство системного администратора. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
5. 5. R. Elz, R. Bush. RFC-2181. Clarifications to the DNS Specification. 1997. (http://www.ietf.org/rfc/rfc2181.txt?number=2181)

Полезные ссылки:

1. http://www.menandmice.com/6000/61_recent_survey.html - результаты исследования Men&Mice по проблемам делегирования зон. Август 2002 года.
2. http://www.dns.net/dnsrd/trick.html#which-server-queried - FAQ. Описание алгоритма выбора сервера среди авторитативных серверов зоны на основе RTT.
3. http://www.caida.org/projects/dns-analysis/#logfile - анализ нагрузки корневых серверов и исследование эффективности алгоритма выбора сервера.
4. http://www2.auckland.ac.nz/net/Internet/rtfm/meetings/47-adelaide/pp-dist/ - материал 2000 года, в котором подмечено совпадение RTT DNS и ping.

Назад Оглавление Вперед