• Обратная зона. Несмотря на то что в большинстве случаев сервер DNS используется для преобразования символьных имен в IP-адреса, сервер имен также должен поддерживать обратное преобразование. Для выполнения подобного преобразования создается зона, имя которой оканчивается на
in-addr.arpa
. Перед этой последовательностью символов указывается имя зоны, т.е. часть IP-адреса, заданная в обратном порядке. Например, запись для сети 192.168.1.0/24 имеет имя
1.168.192.in-addr.arpa
.
В определении зоны указывается тип зоны и список конфигурационных файлов, предоставляющих дополнительную информацию о зоне. Типы зон описаны ниже.
•
master
. Первичный,
или ведущий (master), сервер содержит описание зоны. Если вы создаете сервер DNS для небольшой сети, то, вероятнее всего, объявите локальные зоны как master. Пример зоны такого типа приведен в листинге 18.1.
•
slave
. Вторичный, или ведомый (slave), сервер получает информацию о зоне от другого сервера DNS. Такой сервер также может выступать в роли источника информации о зоне. В следующем разделе данный тип зоны будет рассмотрен более подробно. Простой сервер DNS может выступать для некоторых зон как ведущий, а для других зон — как ведомый.
•
stub
. Сервер такого типа похож на ведомый, но он копирует только записи NS, т.е. спецификации сервера имен. Данный тип зоны следует использовать в том случае, если вы хотите создать отдельный сервер DNS для поддомена. Предположим, что домен
threeroomco.com
содержит поддомен
sub.threeroomco.com
и вы хотите использовать для управления им отдельный сервер DNS. Для этого вы должны включить в состав конфигурационного файла сервера BIND для
threeroomco.com
определение зоны с именем
sub.threeroomco.com
типа
stub
, указывающее на сервер DNS
sub.threeroomco.com
. Вы можете также использовать один сервер DNS для поддержки всего домена, включая поддомен
sub.threeroomco.
com. В этом случае вам не понадобится формировать специальную зону
sub.threeroomco.com
.
•
forward
. Подобно опции
forward
в разделе
options
, зона
forward
сообщает BIND, что запросы на получение информации о зоне должны передаваться другому серверу DNS. BIND формирует собственный запрос к указанному серверу, а затем использует полученные данные для построения ответа. Используя зону такого типа, вы должны включить опцию
forwarders
, указывающую BIND, какому из удаленных серверов DNS должны перенаправляться запросы.
•
hint
. Зона этого типа используется только для описания корневых серверов имен. Она сообщает системе, где следует искать список таких серверов. BIND должен самостоятельно обновлять данный список, обращаясь к корневому серверу имен.
Простой конфигурационный файл, подобный представленному в листинге 18.1, содержит одну зону
hint
и несколько зон
master
. В случае более сложной конфигурации в конфигурационном файле могут быть указаны зоны всех типов.
Настройка ведомого сервера
Если вы собираетесь зарегистрировать домен, вам необходимо настроить два сервера DNS. Обычно один сервер конфигурируют как ведущий, а другой — как ведомый. Как и ведущий, ведомый сервер хранит информацию о зоне в отдельных файлах. Различие между этими серверами состоит в том, что ведомый сервер получает информацию о зонах от ведущего сервера. Для того чтобы это стало возможным, надо задать специальным образом конфигурацию зоны в файле
/еtс/named.сonf
. Предположим, например, что вам необходимо настроить сервер так, чтобы он выполнял функции ведомого по отношению к серверу, конфигурационный файл которого приведен в листинге 18.1. На ведомом сервере зона
threeroomco.com
должна быть определена следующим образом:
zone "threeroomco.com" {
type slave;
file "named.threeroomco.com";
masters { 192.168.1.50; }
};
Приведенная
выше запись указывает на то, что ведомый сервер должен получать содержимое конфигурационного файла для
threeroomco.com
с сервера DNS, расположенного по адресу 192.168.1.50. Если сервер функционирует как ведомый для нескольких доменов, в его конфигурационном файле содержится несколько подобных определений. В списке masters можно указать два и более серверов DNS; их адреса отделяются друг от друга точкой с запятой. (При необходимости ведомый сервер может синхронизировать свое содержимое посредством другого ведомого сервера.) Если сервер является ведомым для нескольких зон, различные зоны могут синхронизироваться от разных ведущих серверов. Эту возможность удобно использовать в том случае, если вы администрируете несколько доменов. Каждый домен обслуживается отдельным ведущим сервером, и для всех их роль ведомого может выполнять один сервер.
Зоны типа
slave
должны быть определены не только для прямого, но и для обратного преобразования адресов (зоны
threeroomco.com
и
1.168.192.in-addr.arpa
, приведенные в листинге 18.1). Для корневых серверов имен и для обратного преобразования localhost (
0.0.127.in-addr.arpa
в листинге 18.1) зоны типа
slave
создавать не надо.
Если сконфигурировав сервер как ведомый, вы запустите его на выполнение, то вскоре увидите, что сервер создал файлы описания зоны, указанные в записях
zone
. Если этого не произошло, необходимо просмотреть файлы протоколов как для ведущего, так и для ведомого сервера и определить причину их некорректной работы. Возможно, что ведущий сервер сконфигурирован так, что передача зоны запрещена. Такой запрет часто устанавливается по соображениям безопасности, чтобы внешние пользователи не могли получить информацию о компьютерах, принадлежащих вашему домену. Если вы хотите ограничить право передачи зоны ведущим или ведомым сервером DNS, вам надо задать опцию
allow-transfer
. Сделать это можно либо в разделе
options
, либо в определении конкретной зоны. Например, чтобы ограничить право передачи зоны компьютерами 192.168.1.0/24 и 172.19.98.23, надо создать следующую запись:
allow-transfer {
192.168.1/24;
172.9.98.23;
};
Управление доменом
Несмотря на то что вы создали файл
/etc/named.conf
, указали в нем глобальные опции и определили зоны, оказывается, что настройка ведущего сервера DNS не закончена и запускать его еще рано. Если в файле
/etc/named.conf
указана зона типа
master
, необходим также конфигурационный файл зоны. В этом файле указываются имена узлов и IP-адреса. Если сервер имен обслуживает домен, содержащий большое число узлов, создание и поддержка файла зоны составляет значительную часть работы по администрированию сети. Если же домен невелик и состояние его не изменяется, достаточно лишь один раз создать конфигурационный файл.
Пример конфигурационного файла зоны
В листинге 18.2 приведен пример простого конфигурационного файла зоны. Этот файл начинается с имени зоны (
threeroomco.com
) и раздела, в котором определяются параметры домена по умолчанию. Эти параметры детально рассматриваются ниже. За этим разделом следует набор записей, предоставляющих информацию о соответствии имен компьютеров и IP-адресов. Некоторые из записей относятся ко всему домену. Подробно структура записей будет рассмотрена позже.