Slave сервер для корпоративного домена. Настройки BIND.

2004 г

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

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

Slave сервер для корпоративного домена. Настройки BIND.

В данном материале мы рассмотрим конфигурацию программы named при организации slave сервера. Основное внимание будет уделено вопросам контроля работы сервера и управления копированием зон с master сервера зоны.

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

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

Slave сервер выполняет процедуру автоматической синхронизации описания зоны на авторитативных серверах, которая в общем виде описана в разделе 4.3.5 RFC 1034.

Согласно этому документу обмен данными между серверами рекомендовано производить по TCP протоколу, используя тип запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).

Важным моментом при обмене данными зоны являются настройки как master, так и slave серверов. Рассмотрим эти настройки более подробно, разбив рассмотрение по версиям BIND.

Настройка slave сервера в BIND 4.x.

Мы будем рассматривать настройку сервера в качестве slave сервера в контексте домена vega.ru, т.е. сервер этого домена будет одновременно выполнять функции slave сервера для другого домена:

directory			/etc/namedb


primary vega.ru                 vega.ru
secondary corp.ru 192.168.0.1 10.0.0.1 corp.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 43.226.194.in-addr.arpa vega.rev
cache   .                       named.root

В данном случае наш сервер размещает файлы описания зон в /etc/namedb. Именно там и появится файл зоны, которую этот сервер с копирует с одного из серверов домена corp.ru.

Сами master серверы прописаны в директиве secondary вслед за именем домена. Всего можно перечислить до 10 IP-адресов серверов, с которых наш сервер может скопировать зону.

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

На самом деле, для slave сервера действуют все те же принципы ограничения доступа к описанию зоны и защите его от повреждения, что и для "прямой зоны".

Во-первых, можно ограничить обслуживание рекурсивных запросов:

directory			/etc/namedb


primary vega.ru                 vega.ru
secondary corp.ru 192.168.0.1 10.0.0.1 corp.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 43.226.194.in-addr.arpa vega.rev
cache   .                       named.root
options	no-recursion

Во-вторых, применить опции снижающие опасность спуфинга сервера:

directory			/etc/namedb


primary vega.ru                 vega.ru
secondary corp.ru 192.168.0.1 10.0.0.1 corp.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 43.226.194.in-addr.arpa vega.rev
cache   .                       named.root
options no-recursion no-fetch-glue fake-iquery

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

Теперь мы можем ограничить число хостов, которым сами разрешаем копировать зону:

directory			/etc/namedb


primary vega.ru                 vega.ru
secondary corp.ru 192.168.0.1 10.0.0.1 corp.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 43.226.194.in-addr.arpa vega.rev
xfrnets		194.226.65.1&255.255.255.255
cache   .                       named.root
options no-recursion no-fetch-glue fake-iquery

В данном случае число таких хостов уменьшили до одного.

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

Настройка slave сервера в BIND 8.x и 9.x.

Настройка BIND 8.x и 9.x отличается синтаксисом и более широкими возможностями по управлению конфигурацией сервера. Для того, чтобы поддерживать slave сервер нам нужно в файл конфигурации вставить код вида:

zone "corp.ru" {
	type slave;
	file "corp.ru";
	masters { 192.168.0.1; 10.0.0.1;};
};

Многие настройки в BIND 8.х и 9.x в файле конфигурации собраны в директиве options. Поэтому их указание в описание зоны не требуется. А вот разрешить, или нет копирование зоны, лучше указывать внутри директивы zone:

zone "43.226.194.in-addr.arpa" {
	type master;
	file "43.226.194.in-addr.arpa";
	allow-query {any; };
	allow-transfer { none; };
};

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

Вообще говоря, прежде, чем запускать сервер, желательно проверить сааму возможность копирования зоны с master сервера на slave сервер. Для этого можно воспользоваться программой dig, например,:

> dig @polyn.kiae.su bard.kiae.ru. axfr

P
; <<>> DiG 8.3 <<>> @polyn.kiae.su bard.kiae.ru. axfr
; (1 server found)
$ORIGIN bard.kiae.ru.
@       1H IN SOA       ns.polyn.kiae.ru. paul.polyn.kiae.su. (
                        7               ; serial
                        1H              ; refresh
                        5M              ; retry
                        16w3d17h46m39s  ; expiry
                        1H )            ; minimum


        1H IN NS        polyn.kiae.ru.
        1H IN NS        iris.polyn.kiae.su.
        1H IN MX        10 mail
        1H IN MX        20 iris.polyn.kiae.ru.
        1H IN A         144.206.192.32
mail    1H IN MX        10 mail
        1H IN A         144.206.192.32
www     1H IN A         144.206.192.32
@       1H IN SOA       ns.polyn.kiae.ru. paul.polyn.kiae.su. (
                        7               ; serial
                        1H              ; refresh
                        5M              ; retry
                        16w3d17h46m39s  ; expiry
                        1H )            ; minimum


;; Received 10 answers (10 records).
;; FROM: generate.polyn.kiae.su to SERVER: 144.206.160.32
;; WHEN: Fri Dec  6 16:37:57 2002
>

Но более правильным было бы использовать саму программу named, а точнее компоненту пакета BIND named-xfer, которая отвечает за копирование зоны на slave сервер:

> /usr/libexec/named-xfer -z bard.kiae.ru -f polyn.db polyn.kiae.su
named-xfer[8443]: send AXFR query 0 to 144.206.160.32
>

В данном случае мы копируем зону (ее описание) bard.kiae.ru в файл polyn.db c сервера polyn.kiae.su. По умолчанию программа использует запрос типа axfr.

Зона после копирования будет выглядеть примерно следующим образом:

; BIND version named 8.2.3-T6B Mon Nov 20 11:24:37 GMT 2000
; BIND version jkh@bento.FreeBSD.org:/usr/obj/usr/src/libexec/named-xfer
; zone 'bard.kiae.ru'   first transfer
; from 144.206.160.32:53 (local 144.206.192.55) using AXFR at
; Fri Dec  6 16:47:3 2 2002
$ORIGIN kiae.ru.
bard    3600    IN      SOA     ns.polyn.kiae.ru. paul.polyn.kiae.su. (
                7 3600 300 9999999 3600 )
        3600    IN      NS      polyn.kiae.ru.
        3600    IN      NS      iris.polyn.kiae.su.
        3600    IN      MX      10 mail.bard.kiae.ru.
        3600    IN      MX      20 iris.polyn.kiae.ru.
        3600    IN      A       144.206.192.32
$ORIGIN bard.kiae.ru.
mail    3600    IN      MX      10 mail.bard.kiae.ru.
        3600    IN      A       144.206.192.32
www     3600    IN      A       144.206.192.32
>

В этом примере стоит обратить внимание на комментарий в начале описания зоны, который программа named-xfer прибавляет от себя. В конце комментария содержится дата копирования зоны.

Named-xfer - это вспомогательный агент (как написано в его документации), который используется в BIND до версии 9.х. В новых серверах этого агента нет. Сервер теперь многопоточный и сам может порождать нить копирования зоны, не мешая обслуживанию запросов к этой зоне.

Распараллеливание процедуры обслуживания обычных запросов к зоне и процедуры копирования зоны было той причиной, по которой появилась программа named-xfer. Речь в данном случае идет о slave сервере. Он при помощи named-xfer запрашивает описание зоны и сохраняет его в файле описания. В этот момент старая копия зоны остается в памяти самого сервера, и он благополучно обслуживает запросы к ней. После получения описания зоны сервер перезагружает описание зоны в своей памяти.

В BIND 9 named-xfer нет. Разработчики рекомендуют использовать dig, если очень нужно получить зону по axfr запросу. Есть только один момент. Программы типа dig, например, host, в точности следуют спецификациям и копируют все что получают. А в качестве ответа на запрос типа axfr запись SOA передается в начале и в конце отклика. Естественно, что конечную запись желательно из файла удалить.

В принципе, slave сервер может не хранить копию зоны у себя в файловой системе. Эта копия нужна только в момент старта. Ее основное назначение - сокращение объем DNS трафика.

Копия не создается, если в директиве secondary BIND 4.х не задано имя файла, или в BIND 8.х и 9.х не задана опция file, которая выполняет аналогичное назначение.

Общие рекомендации, содержащиеся в документации по BIND, советуют все-таки копию описания зоны в файловой системе slave сервера создавать.

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

Можно, конечно, посмотреть работу сервера и при помощи программы dig - отклик должен быть авторитативный.

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

Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
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)
D. Barr. RFC 1912. Common DNS Operational and Configuration Errors. 1996. (http://www.ietf.org/rfc/rfc1912.txt?number=1912)
BIND 9 Administrator Reference Manual. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
BIND Configuration File Guide (8.3.4) (ftp://ftp.isc.org/isc/bind/src/8.3.4/bind-doc.tar.gz)

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

http://www.isc.org/products/BIND/bind8.html - страничка BIND 8.
http://www.isc.org/products/BIND/bind4.html - страничка BIND 4.9.11
http://www.acmebw.com/resources/papers/securing.pdf - Securing an Internet Name Server. CERT Coordination Center. Carnegie Mellon University. 2002. Довольно подробный и обстоятельный обзор возможных проблем безопасности серверов доменных имен с рекомендациями по их (серверов) конфигурации.

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