Управляем зонами DNS

Рашид Ачилов

Сформировать файлы, необходимые для создания собственной зоны DNS, – это еще не все. Необходимо настроить и запустить программу BIND, зарегистрировать доменное имя, дождаться завершения тестов – и можно раздавать друзьям адреса mymail@shortdomain.com!

Настройка BIND

Программа BIND очень богата на параметры конфигурационного файла. Даже простое их перечисление может занять не один лист. Здесь я приведу собственный рабочий конфигурационный файл, слегка измененный к придуманной нами задаче, которая рассматривалась в предыдущей статье «Создаем зоны DNS» (№6 за 2006 г.). Полное руководство по настройке BIND распространяется вместе с дистрибутивом, а также доступно в [1].

Конфигурационный файл BIND – named.conf. Каталог /etc/namedb во FreeBSD обычно содержит этот файл, заполненный настройками по умолчанию, файл named.root, в котором перечисляются «хорошо известные» корневые сервера (этот файл вы можете загрузить с [2]) и шаблон файла обратной локальной зоны PROTO.localhost.rev, на основе которого создается файл localhost.rev.

Настройки named.conf

В качестве знака комментария используется символ «//», как в программах на С++. Допустимо также использование знака «#», как в скриптах на /bin/sh. Порядок задания параметров произвольный.

Первыми идут настройки, относящиеся к системному журналу (syslog). BIND очень богат на опции настройки хранения информации в syslog, перенаправлять ее можно как угодно. В приведенном ниже примере создается канал передачи сообщений (channel) такой, что все сообщения направляются в syslog с facility local7 и severity info. После описания канала задаются категории, указывающие, какие сообщения куда следует направлять. В этом случае все просто, все направляется в один и тот же файл, хотя ничто не помешало бы нам создать несколько каналов и разбросать сообщения между ними.

logging {

        channel named_log {

            syslog local7;

            severity info;

        };

        category default { named_log; default_debug; };

        category general { named_log; default_debug; };

        category unmatched {named_log; default_debug; };

};

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

acl me-white { 212.20.5.0/24; };

acl grayteeth { 10.87.1.0/24; };

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

Создаем внутренние зоны. Для начала определим, кто имеет право получать данные из внутренних зон и то, что для запроса от внутреннего клиента сервер является рекурсивным, то есть не будет в ответ отдавать ссылки на другие сервера (DNS NXDOMAIN), а обязан вернуть ответ на запрос – успешный или неуспешный.

view "internal" {

        match-clients { grayteeth; me-white;};