Настройка BIND с помощью файла named.conf


Содержимое файла named.conf напоминает код на языке С. Если вам не знаком язык С, не волнуйтесь. Правила очень просты, а примеры объясняют все, что вам нужно знать. Если строка начинается с двух символов слэша (//), то это комментарий. А любой текст между старыми добрыми знаками комментариев С (/* и */) — это многострочный комментарий. Все остальное в named.conf — это либо параметры, либо зоны. Зона — это причудливое название домена (строго говоря, они не идентичны, но для наших целей можно сделать такое допущение). Параметры управляют работой BIND.

Параметры

Если не принимать во внимание комментарии, файл named.conf, поставляемый по умолчанию, начинается со списка параметров. Основная их часть неясна и по умолчанию закомментирована. Для применения параметров их нужно разместить в соответствующем разделе, который ограничен словом options и фигурными скобками ({ и }). Сами параметры располагаются между скобками и отделяются друг от друга точкой с запятой. Вот очень простой раздел параметров из файла named.conf:

options {
        directory       "/etc/namedb";
        pid-file        "/var/run/named/pid";
        dump-file       "/var/dump/named_dump.db";
        statistics-file "/var/stats/named.stats";
        listen-on       { 127.0.0.1; 192.168.0.5; };
};

В этом примере значениями большинства параметров являются каталоги или файлы, и только параметр listen-on содержит два IP-адреса.

Сначала рассмотрим параметр directory. Он задает каталог конфигурации, в котором демон named ищет и хранит файлы DNS. Значение по умолчанию — очень неплохой выбор, особенно если учесть, что каталог /etc/namedb в действительности таковым не является. (Странно звучит? Читайте дальше, и вскоре все прояснится.)

Параметр pid-file — это имя файла, в котором хранится числовой идентификатор основного процесса named. Содержимое этого файла используется различными инструментами администрирования сервера имен.

Параметр dump-file — это кэш ответов демона named. Все ответы, отправленные named, сохраняются в кэше на диске. Файл кэша часто используется при поиске неисправностей в DNS.

Если от named требуется, чтобы он сохранял статистику и другие сведения о запросах, эти данные сохраняются в файле statistics-file.

Параметр listen-on определяет, на каких IP-адресах named принимает запросы. Если за одной сетевой картой закреплены десятки IP-адресов, named можно привязать только к одному адресу. Если в системе применяются клетки, такое решение особенно ценно, поскольку предотвращает неправильную настройку клиентов.

BIND поддерживает намного больше параметров, но эти применяются, пожалуй, чаще остальных. Полный список параметров и описание их применения можно найти в документации BIND на сайте http://www.isc.org.

Зоны в named.conf

Неизмененный named.conf описывает три зоны, или домена, которые сервер имен обслуживает по умолчанию: корневую зону (root zone), локальную зону для IPv4 (IPv4 localhost) и локальную зону для IPv6 (IPv6 localhost). Изменять зоны не надо, иначе наверняка будут проблемы. Мы только рассмотрим их назначение.

Корневая зона

Сервер имен обращается к корневой зоне, когда у него нет информации о запрашиваемом домене или хосте. Такие запросы перенаправляются корневому серверу имен. Вот запись в named.conf для корневой зоны:

Первый элемент (1) говорит, для какого домена предназначена эта запись. Точка в кавычках означает, что запись соответствует всему Интернету.

Поле type (2) определяет тип домена. Корневая зона — особая: только она имеет тип hint. Все остальные записи могут иметь тип либо master, либо slave.

Наконец, ключевое слово file (3) сообщает демону named, в каком файле хранится информация для этого домена. Демон обращается к каталогу, указанному в параметре directory, находит файл с этим именем и назначает его содержимое данной зоне. Эти файлы будут рассмотрены позже.

Локальные зоны

Помните, в главе 6 говорилось, что каждый компьютер использует «обратную петлю» (loopback) с IP-адресом 127.0.0.1 для обращения к самому себе? Сервер имен должен содержать записи для этого IP-адреса. Без них каждый системный вызов, запрашивающий имя локального хоста, переходил бы в режим ожидания, существенно замедляя работу системы, что раздражало бы пользователей.

Ниже приводится конфигурация для локальной зоны IPv4. В файле named.conf она расположена сразу после корневой зоны:

Довольно похоже на блок options и корневую зону из предыдущего раздела, не правда ли?

Имя зоны (1) представлено в кавычках после слова zone. Поскольку эта зона применяется для обратного DNS, мы видим IN-ADDR.ARPA. Если данный IP-адрес записать в обратном порядке, получится фактическая группа IP-адресов 127.0.0.

Поле type (2) указывает, является ли данный сервер первичным или вторичным для этого домена. Каждый сервер имен является первичным для локальных зон.

Наконец, ключевое слово file (3) сообщает серверу имен, в каком файле можно найти информацию об этом домене. Информация об этой зоне находится в подкаталоге каталога конфигурации named в файле /etc/namedb/master/localhost.rev.

Версия локальной зоны для IPv6 мало чем отличается от этого блока. Если IPv6 у вас не используется, как и на большинстве других серверов в Интернете, ее можно просто закомментировать.

Настройка вторичного сервера имен

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

Запись выглядит очень знакомой. Здесь есть имя домена (1), тип зоны (2) и имя файла (3), в котором хранится информация о домене. Кроме первичного сервера, у которого можно получить информацию о совместно обслуживаемой зоне, не менее важно знать, за какие записи вы действительно отвечаете и какие из них можно получить у первичного сервера. Кроме того, сервер имен должен иметь право на запись в файлы вторичных зон, но не в файлы первичных зон. По традиции имена файлов вторичных зон образуются добавлением расширения .db к имени домена. Вопреки ожиданиям эти файлы не являются двоичными файлами базы данных. named(8) создает их, когда вторичный сервер загружает данные о домене с первичного сервера.

Далее следует запись о первичном сервере домена (4) со списком его IP-адресов (5). Вторичный сервер запрашивает информацию о домене с первичного сервера через постоянные интервалы времени. Первичный сервер имен должен быть представлен своими IP-адресами; в конце концов, DNS-сервера должен иметь возможность загружать свои записи еще до того, как он узнает IP-адрес чего-либо!

Настройка первичного сервера имен

Конфигурация named.conf, необходимая для первичного сервера, даже проще конфигурации для вторичной зоны:

Итак, еще раз: есть имя домена (1), тип зоны (2) и имя файла (3). В отличие от файла описания домена для вторичного сервера имен, данный файл надо создать. Создание этого файла зоны рассматривается ниже в этой главе.

Хранилище файлов зон для первичного и вторичного серверов имен

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

Всегда отделяйте файлы зон, для которых ваш сервер является первичным, от файлов зон, для которых сервер является вторичным. Конфигурация сервера имен по умолчанию уже включает два таких каталога, но многие начинающие администраторы DNS сваливают все в каталог конфигурации /etc/namedb и потом горько жалеют об этом. Файлы в каталоге первичного сервера священны, и их резервные копии следует хранить в безопасном месте, желательно в репозитарии RCS (глава 4). Файлы из каталога вторичного сервера тоже не мусор, но они не требуют такого же бережного отношения и обязательного резервного копирования.

Если вам предстоит обслуживать несколько тысяч доменов, можно задуматься о более глубокой иерархии каталогов с файлами первичных зон. В прошлом я использовал 36 подкаталогов в каталоге первичного сервера — по одному для каждой буквы и цифры.

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

Комментарии запрещены.