Файлы описания зоны. Директивы управления.

2004 г

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

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

Файлы описания зоны. Директивы управления.

В этом материале мы разберем особенности применения директив управления при описании зон в master файлах. Кроме стандартных директив $ORIGIN и $INCLUDE будут также рассмотрены $TTL и $GENERATE.

Наиболее используемая директива управления - $ORIGIN. Она позволяет определять текущее имя домена. Поясним что это такое. При описании файла конфигурации named в качестве первого параметра директив primary, secondary (файл конфигурации BIND 4) и директивы zone (файл конфигурации BIND 8 или 9) указывается имя зоны, например:

#
# файл настройки для BIND 4
#
directory			/etc/namedb


primary kyky.ru kuku.ry
secondary first.kyky.ru 192.168.0.1 first.kuku.ru

или:

/*
  файл настройки для BIND 9
*/
options {
	directory "/etc/namedb";
};
zone "kyky.ru" in {
	type master;
	file "kyky.ru";
};
zone "first.kyky.ru" in {
	type slave;
	file "first.kyky.ru";
	masters {192.168.0.1;};
};

В обоих примерах в качестве зоны ответственности для master сервера указана зона kyky.ru, а для slave - first.kyky.ru.

Теперь, если перейти к master файлу зоны kyky.ru, т.е. файлу описания зоны kyky.ru, то по умолчанию в качестве текущего доменного имени будет предполагаться имя kyky.ru. Если быть абсолютно точным, то это имя будет содержаться в переменной @. Именно поэтому файл описания зоны kyky.ru начинается записью вида:

@	IN	SOA	ns.kyky.ru. adm.kuku.ru. (
			1 2h 30m 2d 30m )
	IN	NS	ns.kyky.ru.
ns	IN	A	192.168.0.2

Таким образом, записи SOA и NS в данном случае относятся к зоне kyky.ru. А адресная запись определяет IP-адрес для хоста ns.kyky.ru.

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

@	IN	SOA	ns.kyky.ru. adm.kuku.ru. (
			1 2h 30m 2d 30m )
	IN	NS	ns.kyky.ru.
ns	IN	A	192.168.0.2
sub	IN	NS	first.kyky.ru.
first	IN	A	192.168.0.2
$ORIGIN	sub.kyky.ru.
ns	IN	A	192.168.0.45

В этом примере директива $ORIGIN переопределяет имя текущего домена с kyky.ru на sub.kyky.ru.

Можно было бы просто указать полное доменное имя для хоста с адресом 192.168.0.45 - ns.sub.kyky.ru, но это хорошо тогда, когда мы определяем один хост, но довольно утомительно набивать полные имена, если хостов будет много. При этом всегда нужно помнить о точке на конце полного имени J.

Вообще говоря, основное назначение $ORIGIN - это упрощение содержания файла описания зоны при определении поддоменов в той же зоне, где описан и выше стоящий домен:

	$ORIGIN	kyky.ru.
	ns		IN	A	192.168.0.1
	www		IN	A	192.168.0.2
	$ORIGIN	sub1.kyky.ru.
	host1		IN	A	192.168.0.3
	host2		IN	A	192.168.0.4
	$ORIGIN	sub2.kyky.ru.
	host1		IN	A	192.168.0.5
	host2		IN	A	192.168.0.6

В приведенном выше примере мы завели два поддомена в домене kyky.ru, при чем именование машин в них одинаковое, но полные доменные имена различаются, что и не удивительно.

Еще несколько лет назад довольно часто можно было видеть в файлах описания зон следующую картину:

@	IN	SOA	ns.kyky.ru. adm.kuku.ru. (
			1 2h 30m 2d 30m )
	IN	NS	ns.kyky.ru.
	IN	NS	ns.provider.ru.
ns	IN	A	192.168.0.2
$ORIGIN	provider.ru.
ns	IN	A	192.168.10.5

Что тут не так? Формально все верно. Для зоны kyky.ru должно быть определено два сервера доменных имен с независимым подключением к сети, т.к. речь идет о корпоративном домене.

Первый сервер определен в сети компании и имеет имя ns.kyky.ru, а второй сервер - это сервер провайдера, который обеспечивает дублирование, т.е. ns.kyky.ru - это master, а ns.provider.ru - это slave.

Вся штука в том, что имя ns.provider.ru не принадлежит домену kyky.ru. На самом деле наш сервер не является авторитативным для зоны provider.ru, поэтому он не вправе отвечать на запросы к этой зоне.

Тем не менее, существует процедура делегирования зон ответственности, и там возникает ситуация, когда IP-адрес сервера доменных имен нельзя получить иначе, как из зоны, в которой описано делегирование.

В этом случае отклик нашего сервера называют рефералом (refferal) и он содержит IP-адреса серверов доменных имен в качестве дополнительной информации. Эти адресные записи принято называть присоединенными (glue - буквально "приклеенные").

Так вот, присоединять адресную запись для ns.provider.ru нет смысла, т.к. ее можно найти в другой зоне. Более того, там она может оказаться более свежей, чем у нас, и указывающей совсем на другой адрес. Присоединяют только те записи, информацию о которых иначе получить просто нельзя, например, адреса серверов доменных имен, чьи имена находятся в делегируемой нами зоне.

Новые версии BIND (4.9 и выше) отслеживают этот момент, а вот более старые версии такой проверки не делают. Администраторы системы доменных имен включали такие "приклеенные" записи для того, чтобы сэкономить на трафике (нет нужды опрашивать серверы доменных имен).

О "приклеенных" записях подробно поговорим позже при описании адресных и NS записей.

Директива $INCLUDE используется для того, чтобы в файл описания зоны можно было включить содержание другого файла. Так рекомендуется поступать при описании больших зон, разбивая их на небольшие фрагменты. При этом имя включаемого файла должно быть описано либо полностью от корня файловой системы, либо оно будет привязано к директории, указанной в файле named.boot или named.conf.

$INCLUDE my_zone.dsc

В этом случае используется файл /etc/namedb/my_zone.dsc, т.к. обычно директивы directory (BIND 4) или directory (BIND 8-9) определяют именно эту директорию для хранения файлов базы данных named.

$INCLUDE /etc/my_zone

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

Рассмотрим теперь еще две директивы управления, которые сравнительно недавно появились в файлах описания зон: $TTL и $GENERATE.

Директива $TTL определяет время хранения записи описания ресурсов в кэше resolver, а если resolver "глупый" (stub), т.е. не имеет кэша и посылает только рекурсивные запросы, то $TTL будет определять время хранения RR в кэше локального сервера доменных имен, который выполняет запросы "глупого" resolver.

Данная директива была введена в RFC-2308 для того, чтобы освободить последний параметр записи SOA для времени кэширования отрицательных ответов (negative caching).

Директиву $TTL следует указывать прямо перед записью SOA в файле описания зоны. $TTL связана с определением 32-битового значения, поэтому может принимать значения от 0 до 2147483647(RFC 2181).

Вообще говоря, администратор серверов BIND версий 8 или 9 имеет возможность определять максимальное время кэширования для записи описания ресурса. Делается это в файле конфигурации named.conf. По умолчанию это время равно одной неделе.

В материале "Описание зоны. Формат записи описания ресурсов (RR)" было указано, что при переходе со старых версий BIND на новые не нужно изменять файлы описания зон, т.к. формат RR не изменился. Как теперь понятно, это не совсем так. Во всяком случае, изменилось назначение одного из атрибутов SOA и, как следствие стал необходима директива управления $TTL.

Конечно, разработчики BIND понимают, что в сети стоит большое число серверов, о которых администраторы просто забыли, а поэтому в BIND заложены разумные значения времена кэширования (TTL) по умолчанию.

Директива $GENERATE призвана упростить процесс создания фала описания зоны. Ее главное назначение заключается в том, чтобы сократить число регулярных записей, которые отличаются друг от друга одним или несколькими символами. Например, если стандартный набор записей в фале описания зоны выглядит, как:

host1		IN	A	192.168.0.1
host2		IN	A	192.168.0.2
…
host10		IN	A	192.168.0.10

То запись с использованием $GENERATE будет выглядеть примерно так:

$GENERATE 	1-10	$	IN	A	192.168.0.$

Таким образом, 10 записей мы заменили одной.

Очень полезна данная запись в случае, когда нужно определять обратную зону для сети класса С (в нотации CIDR маскированы первые 24 бита), которая разбита провайдером на подсети, и эти подсети розданы различным клиентам (см. RFC 2317). Оставим саму проблему за кадром до того момента, когда нам действительно понадобится делегировать подобного рода обратные зоны, а здесь приведем только ту часть файла описания "обратной" зоны, в которой применяется директива управления $GENERATE:

$GENERATE 1-63 $.0.168.192.in-addr.arpa   IN CNAME $.0-63.0.168.192.in-addr.arpa.
0-63.0.168.192.in-addr.arpa.              IN NS    ns.kyky.ru.


$GENERATE 65-127 $.0.168.192.in-addr.arpa IN CNAME $.64-128.0.168.192.in-addr.arpa.
64-128.0.168.192.in-addr.arpa.            IN NS    ns.corp.ru.

В данном случае $GENERATE используется для производства однотипных RR.

Следует отметить, что $GENERATE это не стандартная директива, а расширение директив управления пакета BIND.

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

P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
H. Eidnes, G. de Groot, P. Vixie. RFC 2317. Classless IN-ADDR.ARPA delegation. 1998. (http://www.ietf.org/rfc/rfc2317.txt?number=2317)
M. Andrews. RFC 2308. Negative Caching of DNS Queries (DNS NCACHE). 1998.(http://www.ietf.org/rfc/rfc2308.txt?number=2308)
R. Elz, R. Bush. RFC 2181. Clarifications to the DNS Specification. 1997. (http://www.ietf.org/rfc/rfc2181.txt?number=2181)
Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.

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

http://www.ispras.ru/~grn/dns/index.html - Г.В. Ключников. Служба доменных имен (Domain Name System). 1999. На самом деле, это отличная компиляция приведенных в конце книжки первоисточников. Примеры взяты из этих же первоисточников. Очень качественный перевод и грамотно скомпонованный текст.
http://public.pacbell.net/dedicated/cidr.html - Classless Inter-Domain Routing (CIDR) Overview. Этот обзор позволяет получить представление о CIDR - концепции, которая пришла на смену маршрутизации на основе классов IP-сетей.

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