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

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

Описание зоны. Формат записи описания ресурсов (RR).

В данном материале речь пойдет о формате master файла (файла описания зоны) сервера доменных имен, о записях описания ресурсов и их основных типах.

Основная информация, ради которой, собственно, и затевалась система доменных имен, - это соответствия между IP-адресами и именами. Эта информация содержится в файлах описания зон (master files) ответственности серверов, или просто - описаниях зон.

Еще раз обратим внимание на то, что зона и домен - это не одно и тоже. Домен - это все поддерево дерева доменных имен. Зона - это тот же домен, но за вычетом делегированных другим серверам частей домена, которые в свою очередь будут называться делегированными зонами. Подробнее смотри в материале "Как работает система доменных имен".

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

Формат записей описания зон определен "по простому" в RFC-1033 и более академично в RFC-1035. К слову сказать, именно поэтому файлы описания зон во всех версиях BIND одинаковые, и если вы решили сменить BIND 4 на BIND 9, то придется переписать только файл конфигурации named, но не файлы описания зон.

Согласно RFC-1035 (секция 5 "Master Files") в файле описания зоны можно использовать следующие директивы:

• [<comment>]
• $ORIGIN [<comment>]
• $INCLUDE [] [<comment>]
• [<comment>]
• [<comment>]

Соответственно, это: комментарий, определение имени текущего домена, вставка внешнего файла и два формата записи описания ресурсов.

Каждая директива занимает ровно одну строку, но если применить круглые скобки "( )", то текст директивы может быть распространен на несколько строк. Любая непустая комбинация пробелов и символов табуляции рассматривается как разделитель между элементами директивы.

В приведенной выше нотации в квадратные скобки ([ ]) заключены необязательные параметры, а в угольные скобки (< >) - сущности. Например, <comment> определяет комментарий. В свою очередь, комментарий - это символ ";" с последующим за ним текстом до конца строки. В следующем фрагменте файла описания зоны:

$ORIGIN kyky.ru.
;
; Zone kyky.ru
;
ns	IN	A	192.168.0.1 ; name server
www	IN	A	192.168.0.2 ; web server

Строки со второй по четвертую включительно будут строками комментария. Пятая и шестая строки заканчиваются комментариями.

Все директивы можно разделить на два типа: директивы управления (control entries) и записи описания ресурсов (resource records - RR). Существует две директивы управления ($ORIGIN и $INCLUDE) и множество RR, большая часть из которых по различным причинам не используется в реальной жизни. Даже тот список записей, что перечислен в RFC-1033, является несколько избыточным.

Вообще-то, директив управления в современных пакетах BIND 8-ой и 9-ой версий больше. К стандартным $ORIGIN и $INCLUDE следует добавить $TTL и $GENERATE.

Формат записи описания ресурса

.

Записи типа RR в master файле (файле описания зоны) имеют формат описанный в RFC-1033 и уточненный в RFC-1035. Приведем его по RFC-1033 как более простому, а отличия от RFC-1035 обсудим дополнительно ниже:

   []   []      

Как и прежде "[ ]" - это опционный, т.е. необязательный, параметр, а "< >" обозначают сущность. Отличие этой формы определения от RFC-1035 заключается в том, что тоже может быть опционным параметром, т.е. его можно опускать в RR, а также и можно менять местами. Более того, если первые три параметра опущены, то действует значение параметра, определенное в предыдущих записях файла, например:

kyky.ru.	IN	NS	kyky.ru.
			A	192.168.0.1
			MX	10 192.168.0.1

В данном случае значение поля name (kyky.ru), значение поля ttl, которое в данном контексте не определено, значение поля class (IN, что означает Интернет) наследуются из записи определения сервера доменных имен(NS RR) адресной записью (A RR) и записью определения почтового посредника (MX RR).

Определим поля записи описания ресурса:

Поле name - это имя объекта. Объектом может быть хост, домен и поддомен. Существуют специальные правила именования объектов, которые базируются на понятии текущего имени домена.

Если в качестве значения поля name указан символ "@", то текущим именем домена является имя, указанное в директивах primary, secondary или cache файла named.boot (BIND 4) или zone файла named.conf (BIND 8 или 9), в зависимости от того, о каком файле базы данных named идет речь. В противном случае для определения текущего имени должна быть указана директива $ORIGIN.

Если имя в записи описания ресурса опущено, то ресурс относится к текущему имени домена. Если имя указано без точки на конце, то оно расширяется текущим именем домена. Для изменения текущего имени домена следует ввести либо команду $ORIGIN, либо указать имя записи ресурса с точкой на конце. Например:

Файл конфигурации named:


zone "kyky.ru" in {
	type master;
	file "kyky.ru";
};


Файл "kyky.ru":


\@	IN	SOA	ns.kyky.ru. user.kuku.ru. (
			1 3h 1h 1w 1h )
	IN	NS	ns.kyky.ru.
ns	IN	A	192.168.0.1
$ORIGIN	kuku.ru.
ns		IN	A	192.168.0.1
www.kyky.ru.	IN	A	192.168.0.2

В выше приведенном пример мы предполагаем, что речь идет о master файле зоны kyky.ru. Именно она у казана в файле конфигурации named (версия BIND 9). Символ "@" в первой позиции первой строки (запись SOA) указывает на то, что текущим именем домена является имя kyky.ru. Для записи описания сервера доменных имен это имя наследуется из записи SOA. Запись описания сервера доменных имен (NS), следовательно относится к домену kyky.ru, т.е. авторитативный сервер доменных для домена kyky.ru называется ns.kyky.ru.

Далее определяется адрес хоста, который имеет имя ns.kuku.ru. При этом вовсе не обязательно указывать имя целиком, т.к. у ns на конце нет символа ".", и, следовательно, данное имя является не полным, и будет расширено до ns.kyky.ru.

Последняя строка определяет адрес для хоста с именем www.kyky.ru, т.к. доменное имя в этом случае заканчивается точкой, то оно не будет расширено значением текущего доменного имени.

Теперь мы переопределяем текущее имя домена при помощи директивы $ORIGIN. Текущее имя домена теперь - kuku.ru. Следовательно, следующая строка будет определять адрес машины ns.kuku.ru.

Если в качестве имени указана одна точка(".") или две точки("..") то такая запись описывает домен root, т.е. корневой домен.

Если в качестве имени указана одна точка(".") или две точки("..") то такая запись описывает домен root, т.е. корневой домен.

Если в имени записи встречается символ "*", то это он означает что вместо него можно подразумевать любую разрешенную последовательность символов. В англоязычных источниках это называют "wildcard character". Для пользователей любой операционной системы употредление этого символа хорошо знакомо по командам dir (MS-DOS) или ls (Unix). Например, при необходимости получить список файлов, оканчивающихся расширением "bak", и только их выдается команда:

/usr/paul>ls *.bak

Точно также используется этот символ и в имени записи базы данных описания домена. Если в поле имени указан только символ "*", то это предполагает "*.<имя текущего домена>. Если за "звездочкой" следует имя, то оно ограничивает расширение имен "звездочкой". Например, "*.polyn.kiae.su." определяет все имена из домена polyn.kiae.su, в том числе и имена машин в поддоменах, а не только имена машин в корне домена и имена самих поддоменов. Наиболее часто "*" используется в записях MX, которые регулируют обмен электронной почтой между Интернет-почтой и другими почтовыми службами.

Не следует, однако, думать, что символ "*" может быть использован где угодно. Место использования маски строго определено - это может быть только первый символ в поле имени текущего домена, отделенный от остальных символом ".".

Если в поле имени указан только символ "*", то он маскирует доменные имена хостов текущего домена. Однако, если для какого либо хоста существуют RR записи, то маска на этот хост не распространяется:

*.kyky.ru.	IN	MX	10 mail.kyky.ru.
first		IN	A	192.168.0.1
sub.kyky.ru.	IN	NS	second.kyky.ru.

В приведенном выше примере, для всех хостов из зоны kyky.ru в качестве почтового посредника должен использоваться хост mail.kyky.ru. Однако, для first.kyky.ru это не так - в описании зоны есть запись описания ресурса для first.kyky.ru.

Кроме того, для делегированной зоны sub.kyky.ru хост mail.kyky.ru тоже не является почтовым посредником, т.к. для делегированных зон согласно RFC-1034 "делегирование прерывает действие маски".

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

Так, например, в RFC-1033 прямо указано, что в имени можно использовать любые восьмибитовые отображаемые символы. При этом, правда сделана ссылка на то, что в других протоколах существуют ограничения, а потому рекомендованы символы "A-Z", "a-z", "0-9", а также символы "-" и "_".

Однако в RFC-1034 принято более жесткое определение того, что такое доменное имя. Из разрешенного списка исключили символ подчеркивания и постановили, что система не различает заглавные и прописные буквы, т.е. имена kuku, KUKU, KuKu - это одно и тоже имя.

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

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

Поле ttl (Time To Live) - это поле определяет время, в секундах, в течение которого данная запись сохраняется в кэше. Максимальное значение поля TTL 4294967295. Ровно такое максимальное положительное число может быть задано при помощи 32 битов (RFC-1035, секция 6.1.3).

В реальной жизни все гораздо менее масштабно. Записи обычно хранятся в кэше часа или около того, что составляет 3600 секунд. Правда для записей корневой зоны TTL умолчания составляет 1 день или 86400 секунд (см. распечатку корневых серверов в материале "Типы серверов доменных имен. Master, Slave, Cache, Stealth, Root.".

Если это поле оставлено пустым, то по умолчанию принемается значение, указанное в параметре minimum поля данных (data) записи SOA для данной зоны(см. описание записи SOA).

Написав предыдущий абзац, мы остались в эпохе до 1998 года, когда вышло RFC-2308 (Отрицательное кэширование DNS запросов). Тем не менее, не стоит его вымарывать их своей памяти, т.к. до версии 8 BIND минимальное время TTL определял согласно RFC-1035, т.е. в записи SOA. Точнее говоря, это было не минимальное время хранения в кэше, а время умолчания.

RFC-2308 ввел два новых понятия: время негативного кэширования и директиву управления $TTL.

Негативное кэширование - это кэширование запросов, которые доставляют информацию о том, что установить соответствие между доменным именем и IP-адресом нельзя по разным причинам.

Если не использовать негативного кэширования, то локальный сервер доменных имен, который обслуживает рекурсивный запрос resolver, либо сам resolver, если он "умный", будут совершать от 2 до 3 попыток разрешить (установить соответствие между доменным именем и IP-адресом) доменное имя, как только какая-либо из прикладных программ, данное имя запросит. При чем повторяться это будет каждый раз, как только новый запрос поступит, т.к. система не помнит результатов предыдущего выполнения запроса.

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

Если в поле TTL указано 0 значение, то тем самым запрещают кэширование такой записи. Например, запись SOA всегда передают со значением 0 в поле TTL, для того, чтобы запретить кэширование.

Поле class определяет класс записи описания ресурса. В Internet используется только один класс записей - класс IN. В принципе существуют еще классы HS(Hessiod) и CH(Chaos), но в рамках нашего контекста - системы доменных имен Internet - они не рассматриваются.

Некоторые авторы, например, Ronny H.Kavli, который написал комментарии к FAQ Kaig Richmond-а, считают, что наличие этого поля только "замутняет чистый лик" базы данных описания ресурсов DNS. В любом случае все записи из базы данных named имеют вид:

  IN  

Поле type определяет тип записи описания ресурсов. К таким типам относятся: SOA (Start Of Authority), NS( Name Server), A(Address), MX(Mail eXchanger) CNAME(Canonical NAME), WKS(Well Known Services), PTR(PoinTeR), HINFO(Host INFOrmation) и др.

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

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

В поле data указываются данные для каждой записи описания ресурсов. Для различных типов записей формат данных также различный и соответствует назначению записи описания ресурсов.

При описании элементов записи описания ресурса можно применять маскирование символов. Маскирование символов применяется в том, случае, если необходимо использовать символ, который имеет особое значение для записей описания ресурсов. Например, символ "@". Для этого используется символ обратного слэша "\". Аналогично языку программирования С символ можно указывать и цифрами. Только в этом случае используется десятичное число, которое соответствует коду ASCII, например, "\040" также обозначает символ "@".

Настоятельно рекомендуем не использовать маскирования символов в файлах описания зон.

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

1. Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
2. BIND 9 Administrator Reference Manual. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
3. P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
4. M. Lottor. RFC-1033. DOMAIN OPERATIONS GUIDE November 1987. (http://www.ietf.org/rfc/rfc1033.txt?number=1033)
5. B. Manning & R. Colella. RFC 1637. DNS NSAP Resource Records. 1994. (http://rfc.sunsite.dk/rfc/rfc1637.html)
6. Everhart, Mamakos, Ullmann & Mockapetris. RFC 1183. New DNS RR Definitions. October 1990. (http://www.ietf.org/rfc/rfc1183.txt?number=1183)
7. M. Andrews. RFC 2308. Negative Caching of DNS Queries (DNS NCACHE). 1998.( http://www.ietf.org/rfc/rfc2308.txt?number=2308)

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

1. http://www.isc.org/products/BIND/bind9.html - страничка BIND 9.2.1
2. http://www.ludd.luth.se/~kavli/BIND-FAQ.html - DNS FAQ. Ответы на большинство вопросов, начинающих и "продвинутых" администраторов. Есть только одно большое НО! Этот материал посвящен BIND версии 4. Но все, что касается описания зоны вполне подходит и для более поздних версий BIND.

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