DNS сервер BIND ­ Дневник ­ Максим Боголепов

BIND является самой распространенной реализацией сервера DNS. Разработка ведется Internet Software Consortium (ISC) (замечание от Makc, организация стала называться Internet Systems Consortium). Лицензия собственная, позволяет использовать продукт бесплатно или за плату (контракт на поддержку). В комплекте с сервером BIND 9 поставляются утилиты DNS, клиентская библиотека DNS resolver, облегченная клиентская библиотека lightweight resolver и соответствующий ей демон lwresd, UDP/921 (по-моему, это очень вредная идея консорциума ISC, нарушающая принцип совместимости ПО).

В статье описываются:

• формат файла настройки;
• ведение журналов, сбор статистики и отладка;
• ключи запуска сервера;
• удаленное управление сервером с помощью rndc;
• автоматизация запуска и обслуживания сервера;
• пример установки сервера для обслуживания клиентов;
• пример установки первичного уполномоченного сервера;
• пример установки вторичного уполномоченного сервера;
• поддомены без делегирования зоны;
• делегирование зоны;
• делегирование обратной зоны не по границе октета;
• DNS в изолированной сети интернет;
• использование расширения TSIG протокола DNS;
• динамические изменения зоны.

 

Формат файла настройки

Файл настройки BIND 9 обычно называется /etc/named.conf (можно изменить при установке). Формат файла зоны стандартен и приведен в описании архитектуры DNS. Утилита named-checkzone проверяет синтаксис файла зоны. В качестве параметра указываются имя зоны и имя файла. Утилита named-checkconf проверяет синтаксис файла настройки. В качестве параметра можно указать имя файла.

Комментарии в файле настройки могут записываться в стиле C, C++ или sh. Строки и идентификаторы, не являющиеся доменными именами, например, имена файлов, обязательно заключать в кавычки.

Во многих местах файла настройки используется такая синтаксическая конструкция, как список-шаблонов-адресов: список через точку с запятой шаблонов адресов, завершающийся точкой с запятой. Шаблон адреса – это либо IP-адрес, либо IP-адрес с указанием числа бит в маске адреса (например, 192.168.0.0/24), либо имя ACL (т.е. ссылка на ранее определенный утверждением acl список-шаблонов-адресов, либо список-шаблонов-адресов в фигурных скобках, либо ключевое слово key с последующим именем ключа (определяется утверждением key). Имена рекомендуется заключать в кавычки. Перед шаблоном адреса может стоять символ отрицания (восклицательный знак). Ключи попали в эту конструкцию, потому что они тоже определяют права доступа, хотя и не имеют отношения к адресам хостов. Исходный адрес сравнивается последовательно с элементами списка до первого успешного соответствия. Если перед этим элементом списка стоит символ отрицания, то процесс завершается и сравнение со всем списком-шаблонов-адресов считается неудачным. Предопределены следующие имена ACL:

• any – соответствует любой хост;
• none – не соответствует никакой хост;>
• localhost – соответствует IPv4 адрес любого интерфейса хоста;
• localnets – соответствует любой IPv4 адрес сети, к которой принадлежит любой интерфейс хоста.

Список-ключей – это список ключей через точку с запятой, завершающийся точкой с запятой.

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

• acl имя-acl { список-шаблонов-адресов }; – (определяет именованный список-шаблонов-адресов);
• controls { inet ip-адрес [port порт-TCP ] allow { список-шаблонов-адресов } keys { список-ключей }; … }; – (каждое предложение inet определяет права доступа (адреса и ключи) к управляющему каналу rndc, открываемому по указанному адресу и номеру порта; номер порта по умолчанию – 953; вместо адреса можно указать символ “*“ – IPv4 адрес любого интерфейса хоста);
• include имя-файла; – (содержимое указанного файла включается в текст файла настройки; очень удобно для включения текста ключей из файла, защищенного от чтения посторонними; может использоваться внутри view);
• key идентификатор-ключа { algorithm hmac-md5; secret “секретная-строка-в-base-64”; }; – (определяет ключ для аутентификации и авторизации: rndc и TSIG определение ключа для TSIG можно описывать внутри утверждения view; использовать ключ можно в утверждениях server, controls и в списке-шаблонов-адресов);
• logging – (настройка журнализации; возможно только одно утверждение данного типа);
• lwres – (настройка сервера для выполнения функций демона lwresd);
• options – (глобальные опции и опции по умолчанию; возможно только одно утверждение данного типа);
• server ip-адрес-удаленного-сервера { опция; … }; (позволяет конкретизировать значения некоторых опций для конкретного сервера);
• trusted-keys – определение ключей DNSSEC;
• view – описание вида (точки зрения) на доменное пространство, различным клиентам может быть представлено различное видение на пространство доменных имен;
• zone – описание зоны.

Утверждение options может содержать следующие предложения:

• version “строка”; – (по умолчанию – реальный номер версии; для отключения обработки надо использовать строку none, а лучше закрыть класс CHAOS из вида совсем, т.к. неизвестно о чем он ябедничает еще; сервер позволяет узнать номер версии с помощью запроса к встроенной псевдозоне bind класса CHAOS:
  host -t txt -c CHAOS version.bind адрес-сервера
• hostname hostname-string; – (по умолчанию – gethostname(); для отключения обработки надо использовать строку none, а лучше закрыть класс CHAOS из вида совсем, т.к. неизвестно о чем он ябедничает еще; сервер позволяет узнать имя конкретного хоста из группы anycast с помощью запроса к встроенной псевдозоне bind класса CHAOS (на моем сервере не заработало, попытка указать hostname приводит к сообщению о неизвестной опции):
  host -t txt -c CHAOS hostname.bind адрес-сервера
• directory имя-каталога; – (абсолютное имя рабочего каталога, все упоминаемые относительные имена файлов лежат в нем);
• key-directory имя-каталога; – (абсолютное имя каталога, в котором лежат публичные и частные ключи для безопасного изменения зон; отдельный каталог может потребоваться для увеличения безопасности);
• tkey-domain доменное-имя;
• tkey-dhkey имя-ключа этикетка-ключа;
• dump-file имя-файла; – (named_dump.db; имя файла, в который сбрасывается текущее состояние кеша доменных имен по команде rndc dumpdb);
• memstatistics-file path_name; – (не реализовано);
• pid-file имя-файла; – (/var/run/named.pid; в этот файл записывается номер процесса; можно указать none);
• statistics-file имя-файла; – (named.stats; к этому файлу добавляется статистика по команде rndc stats);
• zone-statistics yes/no; – (no; собирать статистику отдельно для каждой “своей” зоны);
• auth-nxdomain yes/no; – (no; всегда устанавливать бит AA в ответах NXDOMAIN, даже если сервер не является уполномоченным для данного домена; может потребоваться для совместимости);
• dialup dialup_option; – (позволяет уменьшить число дозвонов, если сервер находится на клиентском конце dialup-on-demand линии);
• has-old-clients yes/no; – (устарело; используйте auth-nxdomain yes и rfc2308-type1 no);
• host-statistics yes/no; – (не реализовано);
• minimal-responses yes/no; – (no; заполнять дополнительные секции в ответах только при крайней необходимости – отрицательный результат, делегирование; уменьшает нагрузку на сервер);
• notify yes/no/explicit; – (yes; посылать DNS NOTIFY при изменении зоны, для которой сервер уполномочен, серверам из NS и also-notify explicit – посылать только серверам из списка also-notify;
• recursion yes/no; – (yes; обслуживать рекурсивные запросы);
• rfc2308-type1 yes/no; – (не реализовано);
• forward – (only | first) ; (first; действует только при непустом списке forwarders; перенаправлять запросы, не имеющие ответов в кеше или своих зонах, серверам, указанным в списке forwarders; позволяет организовать общий кеш для нескольких серверов или доступ в Интернет через прокси; first – сначала делается запрос к серверам из списка, при неудаче производится собственный поиск; only – собственный поиск не производится;
  можно настраивать отдельно для каждой зоны – см. утверждение zone);
• forwarders { ip_addr [port ip_port]; … }; – (пусто; список IP-адресов и, возможно, номера портов серверов, которые будут обслуживать перенаправленные запросы; смотри forward);
• check-names ( master | slave | response )( warn | fail | ignore ); – (не реализовано, т.е. ignore?);
• allow-notify { список-шаблонов-адресов }; – (первичный сервер зоны; от кого наш сервер как вторичный уполномоченный сервер будет принимать извещения об изменениях зоны; можно настраивать отдельно для каждой зоны – см. утверждение zone);
• allow-query { список-шаблонов-адресов }; – (any; от кого принимать обычные запросы; можно настраивать отдельно для каждой зоны – см. утверждение zone);
• allow-transfer { список-шаблонов-адресов }; – (any; от кого принимать запросы на передачу зоны; можно настраивать отдельно для каждой зоны – см. утверждение zone);
• allow-recursion { список-шаблонов-адресов }; – (any; от кого принимать рекурсивные запросы; данные из кеша под запрет не попадают);
• allow-update-forwarding { список-шаблонов-адресов }; – (none; от каких хостов вторичный сервер будет принимать динамические изменения зоны для передачи их первичному уполномоченному серверу; авторы не советуют);
• allow-v6-synthesis { список-шаблонов-адресов }; – none; заморочки со “старыми” реализациями IPv6);
• blackhole { список-шаблонов-адресов }; – (none; с этих адресов запросы не принимаются и к ним запросы не посылаются);
• listen-on [ port ip_port ] ; (по умолчанию – все интерфейсы, порт 53; адрес и порт для приема запросов; может быть несколько таких предложений);
• listen-on-v6 [ port ip_port ] { список-шаблонов-адресов }; – (none; для IPv6);
• query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ] ; – (обратный адрес и номер порта для запросов к другим серверам; по умолчанию или * в качестве адреса – INADDR_ANY; по умолчанию или * в качестве номера порта – случайный непривилегированный порт; в TCP запросах всегда используется случайный непривилегированный порт);
• query-source-v6 … – (для IPv6);
• also-notify { ip_addr port ip_port ; … ] }; – (по умолчанию – пустая строка; список адресов серверов, которым посылается DNS NOTIFY при изменении зоны, для которой сервер уполномочен, в дополнение к серверам из списка NS; см. предложение notify и утверждение zone);
• max-transfer-time-in число-минут; – (120; максимальное время приема зоны);
• max-transfer-time-out число-минут; – (120; максимальное время передачи зоны);
• max-transfer-idle-in число-минут; – (60; максимальное время отсутствия прогресса при приеме зоны);
• max-transfer-idle-out число-минут; – (60; максимальное время отсутствия прогресса при передаче зоны);
• serial-query-rate раз-в-секунду; – (20; максимальное число запросов SOA в секунду со стороны нашего сервера как вторичного уполномоченного сервера к соответствующим первичным серверам для определения необходимости приема зоны);
• transfer-format ( one-answer | many-answers ) ; – (many-answers; при выборе формата one-answer при передаче зоны используется отдельный пакет для каждой RR, many-answers – в каждый пакет упаковывается столько RR, сколько в него может поместиться; many-answers эффективнее, но не поддерживается BIND 4; см. утверждение server);
• transfers-in число; – (10; максимальное число одновременно принимаемых зон);
• transfers-out число; – (10; максимальное число одновременно передаваемых зон);
• transfers-per-ns число; – (2; максимальное число одновременно принимаемых зон с одного сервера; см. утверждение server);
• transfer-source ( ip4_addr | * ) [ port ip_port] ; – (по умолчанию – адрес интерфейса, “ближайшего” по мнению ОС к удаленному серверу; определяет локальный адрес при запросе передачи зоны от удаленного сервера; также определяет адрес и UDP порт для перенаправляемых динамических изменений и проверок изменения зоны на первичном сервере (запрос SOA); именно этот адрес должен быть разрешен для передачи на удаленном сервере, так что рекомендуется задавать его явно; см. утверждения server и view);
• transfer-source-v6 … – (передача зоны осуществляется с помощью IPv6);
• notify-source ( ip4_addr | * ) [port ip_port] ; – (?; определяет локальный адрес и UDP порт при посылке DNS NOTIFY вторичным серверам; именно этот адрес должен быть указан при настройке вторичного сервера в предложении master или allow-notify; см. утверждения zone и view);
• notify-source-v6 … – (посылка DNS NOTIFY осуществляется с помощью IPv6);
• max-journal-size размер; – (unlimited; максимальный размер журнального файла – хранит динамические изменения (RFC 2136, RFC 3007) описания зоны на первичном сервере или результат обновлений зоны в формате IXFR (RFC 1995) на вторичном сервере; имя файла образуется из имени зоны добавлением суффикса .jnl; файл имеет двоичный формат; изменения отображаются на файл зоны с некоторым интервалом с целью уменьшения нагрузки на компьютер, поэтому файл зоны нельзя редактировать вручную; используется для восстановлении файла зоны при перезапуске);
• coresize размер; – (default, т.е. значение заданное при запуске процесса, см. setrlimit(2) и ulimit -c; размер coredump; можно использовать масштабирующие коэффициенты K, M и G);
• datasize размер; – (default, т.е. значение заданное при запуске процесса, см. setrlimit(2) и ulimit -d; максимальный размер сегмента данных, который ОС выделит процессу; рекомендуется использовать только для увеличения недостаточного значения по умолчанию; можно использовать масштабирующие коэффициенты K, M и G);
• files число; – (unlimited; максимальное число одновременно открытых файлов);
• stacksize размер; – (default, т.е. значение заданное при запуске процесса, см. setrlimit(2) и ulimit -s; максимальный размер сегмента стека, который ОС выделит процессу; можно использовать масштабирующие коэффициенты K, M и G;
• cleaning-interval число-минут; – (60; период очистки кеша от RR с истекшим TTL);
• heartbeat-interval number; – (для dialup-ных зон);
• interface-interval число-минут; – (60; интервал сканирования списка активных интерфейсов; 0 – сканировать только при запуске; сервер перестает прослушивать опущенные интерфейсы и начинает прослушивать вновь появившиеся при условии, что они подходят под шаблон listen-on);
• statistics-interval number; – (не реализовано);
• topology { список-шаблонов-адресов }; – (не реализовано);
• sortlist { список-шаблонов-адресов }; – (предложение позволяет организовать сортировку RR по адресу в ответе клиенту в зависимости от адреса клиента; правильно настроенный клиент должен делать это сам, настраивать это на сервере – утомительно);
• rrset-order { [ class класс-записи ] [ type тип-записи ] [ name “доменное-имя” ] order ( fixed | random*> | *cyclic ) ; … }; – (по умолчанию: class – ANY, type – ANY, name – *; предложение позволяет отсортировать RR в ответе клиенту в зависимости от класса, типа и значения доменного имени; fixed – не менять порядок записей; random – перемешивать записи в случайном порядке; cyclic – при каждом запросе первой ставится очередная запись; действует только последнее предложение rrset-order в списке; не реализовано; сервер возвращает RR в случайном порядке?);
• lame-ttl число-секунд; – (600; кешировать информацию о неверном делегировании зон (lame-server), чтобы уменьшить нагрузку на журнал; не более 1800; похоже, что кеширование не реализовано?);
• max-ncache-ttl число-секунд; – (10800; максимальное время хранения в кеше отрицательных ответов; не более 7 дней – 604800 секунд);
• max-cache-ttl число-секунд; – (604800; максимальное время хранения в кеше положительных ответов);
• sig-validity-interval число-дней; – (30; время окончания действия цифровых подписей, автоматически генерируемых при динамическом обновлении DNSSEC зоны; время начала действия подписи – за час до текущего времени; не более 3660 дней);
• min-roots number; – (не реализовано);
• provide-ixfr yes/no; – (yes; отвечает как первичный сервер на запросы на передачу обновленной зоны в формате изменений – IXFR; данная опция нужна только для борьбы с ошибочной реализацией IXFR на удаленном сервере; см. утверждение server);
• request-ixfr yes/no; – (yes; запрашивает как вторичный сервер передачу обновлений зоны в формате изменений – IXFR; если удаленный сервер не поддерживает IXFR, то автоматически происходит откат к протоколу AXFR, данная опция нужна только для борьбы с ошибочной реализацией IXFR на удаленном сервере; см. утверждение server);
• ixfr-from-differences yes/no; – (no; вычисление и запись в журнал разницы между старым и новым содержимым зоны для последующей передачи ее в формате IXFR);
• min-refresh-time число-секунд; – (ограничивает интервал обновления зоны, указанный в SOA; см. утверждения view*> и *zone);
• max-refresh-time число-секунд; – (ограничивает интервал обновления зоны, указанный в SOA; см. утверждения view*> и *zone);
• min-retry-time число-секунд; – (ограничивает интервал повтора попыток обновления зоны, указанный в SOA; см. утверждения view и zone);
• max-retry-time число-секунд; – (ограничивает интервал повтора попыток обновления зоны, указанный в SOA; см. утверждения view и zone);
• port ip_port; – (53; номер TCP и UDP портов, который сервер будет использовать для приема и передачи пакетов; применимо только для отладки);
• additional-from-auth yes/no; – (yes; можно отключать только при отключении обслуживания рекурсивных запросов; заполнять дополнительную секцию ответа, если эта информация есть в “своих” зонах);
• additional-from-cache yes/no; – (yes; можно отключать только при отключении обслуживания рекурсивных запросов; заполнять дополнительную секцию ответа, если эта информация есть в кеше);
• random-device path_name; – (/dev/random; устройство или файл в качестве источника случайных чисел);
• max-cache-size размер; – (unlimited; максимальный размер памяти, выделяемой под кеш; можно использовать масштабирующие коэффициенты K, M и G);
• tcp-clients число; – (100; максимальное число одновременно обслуживаемых TCP соединений);
• recursive-clients число; – (1000; максимальное число одновременно обслуживаемых запросов; каждый запрос требует 20 КБ памяти);
• match-mapped-addresses yes/no; – (для IPv6);
• root-delegation-only [exclude { “имя”; … } ]; – (корневые зоны и зоны первого уровня, кроме списка исключений (“DE”, “LV”, “US”, “MUSEUM”), должны только делегировать подзоны).

Утверждение server может использоваться на верхнем уровне файла настройки или быть вложено в утверждение view. Если утверждение view содержит хотя бы одно утверждение server, то для данного вида используются только они (глобальные утверждения server игнорируются), иначе глобальные утверждения server действуют и на данный вид. Утверждение server может содержать следующие предложения:

• bogus yes/no; – (no; не отправлять запросы данному серверу);
• provide-ixfr yes/no; – (позволяет изменить значение опции, заданной глобально или для данного вида);
• request-ixfr yes/no; – (позволяет изменить значение опции, заданной глобально или для данного вида);
• edns yes/no; – (yes; пытаться ли использовать EDNS; ?);
• transfers число; – (позволяет изменить значение опции transfers-per-ns, заданной глобально);
• transfer-format ( one-answer | many-answers ) ; – (позволяет изменить значение опции, заданной глобально);
• keys { string; … } ; – (задает идентификатор ключа для подписи сообщения TSIG для данного сервера; ответ не обязан быть подписан этим ключом; реализован только один ключ на сервер).

Утверждение zone устанавливает опции, специфические для указанной зоны. Формат утверждения следующий:

zone имя-зоны [ класс ] {
  type тип-зоны;
  [ опция; ... ]
  };

Имя зоны – это доменное имя корневого узла зоны.
Тип зоны определяет роль, которую сервер будет исполнять для этой зоны:

• master – сервер является первичным уполномоченным сервером для данной зоны, т.е. загружает содержимое зоны из файла зоны, указанного опцией file;
• slave – сервер является вторичным уполномоченным сервером для данной зоны; содержимое зоны считывается от одного из серверов, указанных в опции masters; указание имени файла в опции file позволяет сохранять резервную копию зоны в файле;
• hint – позволяет задать с помощью опции file имя файла, содержащего описание корневой зоны; этот файл можно взять в Internic; сервер при загрузке обращается к одному из корневых серверов, перечисленных в этом файле, для получения текущего списка корневых серверов; полученный список используется в течении указанного TTL; для класса IN имеется встроенный список предполагаемых корневых серверов;
• stub – использовался в предыдущих версиях BIND для упрощения настройки; использовать не рекомендуется;
• forward – позволяет задавать список серверов, к которым будут перенаправляться запросы, не имеющие ответа в кеше, отдельно для данной зоны (см. предложения forward и forwarders в утверждении options);
• delegation-only – эта зона может содержать только записи о делегировании подзон.

Опции зоны (большинство опций позволяют заменить глобальные значения, заданные в утверждении options или взятые по умолчанию; они имеют тот же самый синтаксис и семантику):

• masters [port ip_port] { ip_addr [port ip_port] [key ключ]; […] }; – (адреса и номера портов серверов, с которых брать содержимое зоны; порт 53 по умолчанию; номер порта перед списком задает общий номер порта для всех серверов; если указано несколько серверов, то они опрашиваются все, а зона запрашивается с того из них, у кого она имеет наибольший серийный номер; указание ключа позволяет проверять правильность передачи с помощью цифровой подписи TSIG);
• file “имя-файла”; (имя файла, в котором хранится содержимое зоны);
• allow-update { список-шаблонов-адресов }; – (none; каким хостам разрешено посылать динамические изменения зоны первичному серверу; права доступа на основе IP адресов опасны! используйте только списки шаблонов на основе ключей);
• update-policy { update_policy_rule […] } ; – (позволяет задать правила доступа на изменение отдельных записей при динамическом изменении зоны на основе авторства (identity) сообщений; имя автора извлекается из подписи TSIG или SIG; применим только для первичного сервера; несовместим с allow-update; правила рассматриваются по очереди до первого совпадения автора, имени и типа; каждое правило состоит из ключевого слова grant или deny, имени автора, способа сравнения имен, полного доменного имени и списка типов (м.б. опущен); в качестве автора можно указывать имя ключа, используемого для создания TSIG или SIG или разделяемого секрета TKEY, а также шаблон (?); опущенный список типов соответствует любому типу, кроме SIG, NS, SOA и NXT; тип ANY соответствует любому типу, кроме NXT); допустимы следующие способы сравнения:
  — name – (посимвольное сравнение);
  — subdomain – (изменяемое имя должно быть поддоменом или совпадать с указанным в правиле);
  — wildcard (?);
  — self – (изменяемое имя должно соответствовать имени автора, имеет смысл если для каждого изменяемого доменного имени создается ключ с таким же именем, а в качестве имени автора указывается шаблон *);
• database “string”; – (тип БД для хранения содержимого зоны во время работы; по умолчанию – “rbt”; другие типы БД необходимо явно указывать при сборке);
• delegation-only yes/no – (эта зона может содержать только записи о делегировании подзон; только для зон типа stub или hint);
• allow-notify – описание см. в утверждении options;
• allow-query – описание см. в утверждении options;
• allow-transfer – описание см. в утверждении options;
• allow-update-forwarding – описание см. в утверждении options;
• also-notify – описание см. в утверждении options;
• check-names (warn|fail|ignore); – (не реализовано);
• dialup – описание см. в утверждении options;
• forward – описание см. в утверждении options;
• forwarders – описание см. в утверждении options, только для зоны типа forward;
• max-transfer-idle-in – описание см. в утверждении options;
• max-transfer-idle-out – описание см. в утверждении options;
• max-transfer-time-in – описание см. в утверждении options;
• max-transfer-time-out – описание см. в утверждении options;
• notify – описание см. в утверждении options;
• pubkey number number number string ; (не реализовано);
• transfer-source – описание см. в утверждении options;
• transfer-source-v6 – описание см. в утверждении options;
• notify-source – описание см. в утверждении options;
• notify-source-v6 – описание см. в утверждении options;
• zone-statistics – описание см. в утверждении options;
• sig-validity-interval – описание см. в утверждении options;
• min-refresh-time – описание см. в утверждении options;
• max-refresh-time – описание см. в утверждении options;
• min-retry-time – описание см. в утверждении options;
• max-retry-time – описание см. в утверждении options;
• ixfr-from-differences – описание см. в утверждении options;
• key-directory – описание см. в утверждении options.

Утверждение view позволяет выдавать различные ответы на один и тот же запрос в зависимости от того, кто спрашивает. То есть вид доменного пространства будет зависеть от точки зрения. Берётся первый подходящий вид в зависимости от адреса клиента (match-clients) или сервера (match-destinations). Если не определено ни одного вида, то по умолчанию создаётся вид “default” в классе IN, в который попадают описания всех зон для всех клиентов. Если хотя бы один вид описывается явно, то все зоны должны быть внутри видов. Формат утверждения следующий:

view имя-вида [ класс ] { 
  match-clients { список-шаблонов-адресов }; 
  match-destinations { список-шаблонов-адресов }; 
  match-recursive-only { yes/no };
  [ опция; ... ]
  [ определение зоны; ... ]
  ;

Чтобы принять 2 вида зоны slave сервер должен иметь 2 адреса, на которые будут передаваться различные виды.

Похоже, что BIND 9 не обслуживает передачу зон, для которых он не является уполномоченным.

 

Ведение журналов, сбор статистики и отладка

Утверждение logging позволяет задать произвольное число способов записи в журнал с помощью предложений channel и привязать различные категории сообщений к каналам с помощью предложений category. Описано в документации мутно (особенно про отладку) и точно так же работает (например, rndc reload не отключает часть отладочной печати).

В предложении channel задается имя канала, способ записи (в файл с ограничением его размера (можно использовать масштабирующие коэффициенты K, M и G) и числа версий, syslog, stderr, null), фильтр (минимальный уровень серьезности сообщений для вывода через этот канал) и формат вывода (выводить ли в каждое сообщение имя категории, уровень серьезности и метку времени; по умолчанию – нет):

channel имя-канала {
     (file имя-файла
         [ versions ( число | unlimited ]
         [ size максимальный-размер ]
       | syslog syslog_facility
       | stderr
       | null );
     [ severity ( critical | error | warning | notice | info | debug [ уровень ] | dynamic ); ]
     [ print-category yes/no; ]
     [ print-severity yes/no; ]
     [ print-time yes/no; ]
     };

Версии файла (file, file.0, file.1 и т.д.) перенумеровываются при каждом открытии, если максимальный размер файла не задан. Если задан и размер и число версий, то перенумеровывание при открытии происходит только при превышении этого размера. Если при записи в файл его максимальный размер будет превышен, то при указании числа версий происходит перенумерация файлов и открывается новый, если число версий не указано, то запись в файл просто прекращается.

Режим отладки задается либо при запуске (ключ -d), либо командой trace программы rndc (выключается командой rndc notrace). Команда trace позволяет указать уровень отладки (чем больше уровень, тем более подробная отладочная информация выдается, уровень 3 достаточно болтлив). При указании фильтра (severity) можно указать определенный уровень отладки (debug [ уровень ]) для включения отладочной печати данного уровня (и ниже) независимо от уровня отладки сервера (лишь бы ее включили) или указать ключевое слово dynamic для отладочной печати уровня, совпадающего с уровнем отладки сервера.

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

category имя-категории {
     имя-канала;> [ имя-канала; ... ]
     };

Определены следующие категории:

• default – (определяет каналы для тех категорий, каналы для которых не определены явно; queries при этом не включается);
• general – (неотсортированные в другие категории сообщения);
• database – (хранение зон и кеш);
• security – (при уровне отладки 3 – разрешения и запрещения, наличие подписей);
• config – (разбор файла настройки);
• resolver – (выполнение рекурсивных запросов клиентов, обращение к другим серверам, объем выдачи зависит от уровня отладки);
• xfer-in
• xfer-out
• notify
• client – (обработка клиентских запросов и посылка ответов, уровень отладки 3);
• unmatched – (отсутствует класс или view);
• network
• update
• queries – (включается командой rndc querylog; явная привязка этой категории к каналам также включает трассировку – severity info);
• dispatch – (передача запросов между модулями bind);
• dnssec
• lame-servers (severity info)
• delegation-only – (ответы NXDOMAIN в результате действия опции delegation-only).

Переопределять каналы (в т.ч. встроенные) нельзя, но можно привязать категории к новым каналам. Сообщения об ошибках синтаксиса файла настройки и о запуске сервера записываются как будто утверждение logging отсутствует (так что syslog:daemon тоже надо просматривать регулярно). По умолчанию принимается следующая настройка записи в журнал:

logging {
  channel default_syslog {
    syslog daemon;
    severity info;
  };
  channel default_debug {
    file "named.run";
    severity dynamic;
  };
  channel default_stderr {
    stderr;
    severity info;
  };
  channel null {
   null;
  };
  category default { default_syslog; default_debug; };
  category unmatched { null; };
};

Количество статистической информации, собираемой BIND 9 сильно уменьшилось о сравнению с предыдущими версиями. Накопленная статистика добавляется командой rndc stats к файлу named.stats в рабочей директории (options, directory), очередной раздел обрамляется строками “Statistics Dump” с указанием времени в формате UNIX:

• success – число запросов, не вызвавших ошибок или возврата клиенту ссылки;
• referral – число запросов, на которые сервер вернул клиенту ссылки;
• nxrrset – несуществующих записей запрошенного типа для доменного имени;
• nxdomain – несуществующих доменных имен;
• recursion – число запросов, потребовавших рекурсивной обработки;
• failure – число ошибок, кроме nxrrset и nxdomain.

Общее число запросов к серверу равно success + referral + nxrrset + nxdomain + failure. Статистика может собираться отдельно по зонам и видам, в этом случае имена зоны и вида (опускается для вида default) приводятся в конце каждой строки.

Немного местной статистики (кеширующий сервер; большую часть нагрузки создают почтовые серверы из-за RBL ;): 4.4 запроса в секунду; средний размер пакета – 100 байт; устоявшийся размер процесса – 16 МБ; нагрузка на процессор – втрое меньше, чем squid, обслуживающий тот же контингент пользователей.

 

Запуск сервера

Рекомендуется создать специальную группу named и пользователя named для запуска сервера. Перед запуском необходимо отредактировать /etc/named.conf, файлы зон и установить соответствующие права доступа к ним и прочим файлам, имеющим отношение к серверу (простой пример). Если необходимо управление сервером с помощью программы rndc, то необходимо также отредактировать /etc/rndc.conf. Ключи запуска:

• -c имя-файла-настройки – (полное имя файла);
• -d уровень-отладки;
• -f – (не уходить в фоновый режим при запуске);
• -g – (не уходить в фоновый режим при запуске, вся отладочная печать на stderr);
• -p номер-обслуживаемого-порта
• -u идентификатор-пользователя – (сменить эффективный идентификатор пользователя с root на указанный как можно скорее после запуска).

После отладки процесс запуска можно автоматизировать.

 

rndc – управление DNS сервером BIND 9

В то время как управление работающим сервером BIND 4 осуществлялось простой посылкой сигнала процессу (HUP перезагрузить файл настройки и зоны; TERM – остановить; INT – сбросить базу данных в файл named_dump.db; ABRT – записать статистику в конец файла named.stats), управление сервером BIND 9 производится с помощью специальной утилиты rndc, которая соединяется с сервером (по умолчанию TCP порт 953) и использует специальный протокол для передачи ему команд. Однако сигналы HUP, TERM пока действуют.

Настраивая сервер, необходимо обеспечить права доступа к управляющему порту (controls) и ключ (key), смотри ниже rndc-confgen.

Файл настройки rndc (/etc/rndc.conf) имеет такой же синтаксис, что и named.conf. Комментарии могут записываться в стиле C, C++ или sh. Файл настройки состоит из утверждений, завершающихся точкой с запятой. Утверждения содержат блок предложений, заключенный в фигурные скобки. Предложение в блоке также завершается точкой с запятой. Права на чтение этого файла должны быть только у того, кто имеет право запускать rndc. Предусматриваются следующие типы утверждений:

• options {
  — default-server имя-или-адрес-сервера;
  — default-key “имя-ключа“;
  — default-port номер-управляющего-порта;
  }
• server имя-или-адрес-сервера { // адрес в двойных кавычках
  — key “имя-ключа“;
  — port номер-управляющего-порта;
  }
• key “имя-ключа“
  — algorithm hmac-md5;
  — secret “base-64-кодированный-ключ“;
  }

Утилита rndc-confgen позволяет сгенерировать /etc/rndc.conf со случайным ключом (и закоментированные предложения controls и key для /etc/named.conf). Следующими ключами можно модифицировать получаемый файл:

• -b размер-ключа – (по умолчанию – 128; от 1 до 512);
• -k имя-ключа – (по умолчанию – rndc-key);
• -p номер-управляющего-порта – (по умолчанию – 953);
• -s имя-или-адрес-сервера – (по умолчанию – 127.0.0.1).

Утилита rndc позволяет менять параметры соединения с сервером с помощью ключей:

• -c имя-файла-настройки;
• -s имя-или-адрес-сервера;
• -p номер-управляющего-порта;
• -y имя-ключа;
• -V (трассировка исполнения для отладки).

Если запустить rndc без указания команды, то она выдаст список поддерживаемых команд:

• reload – (перезагрузить файл настройки и зоны);
• reload зона [класс [вид]] – (перезагрузить зону);
• refresh зона [класс [вид]] – (запланировать немедленное обновление зоны);
• reconfig – (перезагрузить файл настройки и новые зоны);
• stats – (записать статистику в конец файла named.stats);
• querylog – (включить/выключить журнализацию запросов);
• dumpdb – (сбросить базу данных в файл named_dump.db);
• stop – (сохранить изменения в файлы зон и остановить сервер);
• halt – (остановить сервер без сохранения изменений);
• trace – (увеличить уровень отладки на 1);
• trace уровень – (установить уровень отладки);
• notrace – (отключить отладку);
• flush – (сбросить весь кеш);
• flush вид – (сбросить кеш для указанного вида);
• status – (показать состояние сервера);
• restart – (перезапустить сервер; не реализовано).

 

Автоматизация запуска сервера

Автоматизация запуска производится через стандартный в Linux механизм /etc/rc.d/. Кстати, можно позаимствовать скрипты из какого-нибудь дистрибутива. Для работы этих скриптов необходимо предварительно настроить сервер, включая управление через rndc, и создать пользователя и группу named.

Создается файл /etc/rc.d/init.d/named следующего вида (реальный файл из дистрибутива будет содержать множество проверок):

 #!/bin/bash
 # chkconfig: - 55 45
RETVAL=0
prog="named"
start() {
        # Start daemons.
        if [ -n "`/sbin/pidof named`" ]; then
                echo -n $"$prog: already running"
                return 1
        fi
        echo -n $"Starting $prog: "
        base=$prog
        /usr/local/sbin/named -u named
        RETVAL=$?
        usleep 100000
        if [ -z "`/sbin/pidof named`" ]; then
                # The child processes have died after fork()ing, e.g.
                # because of a broken config file
                RETVAL=1
        fi
        [ $RETVAL -ne 0 ] && failure $"$base startup"
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/named && success $"$base startup"
        echo
        return $RETVAL
}
stop() {
        # Stop daemons.
        echo -n $"Stopping $prog: "
        /usr/local/sbin/rndc stop
        RETVAL=$?
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named || {
                killproc named
                RETVAL=$?
                [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named
        }
        echo
        return $RETVAL
}
status() {
        /usr/local/sbin/rndc status
        return $?
}
restart() {
        stop
        start
}
reload() {
        /usr/local/sbin/rndc reload >/dev/null 2>&1
        return $?
}

Не забудьте дать ему права на исполнение:

 # chmod 755 /etc/rc.d/init.d/named

Включение его при загрузке и пробный запуск:

 # chkconfig --add named
 # chkconfig --level 2 named on
 # chkconfig --level 3 named on
 # chkconfig --level 4 named on
 # chkconfig --level 5 named on
 # /etc/rc.d/init.d/named start

Проверяем, запустился ли:

 # /etc/rc.d/init.d/named status

 

Неуполномоченный сервер

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

1. Создаем пользователя и группу named (25):

 # /usr/sbin/useradd -c "Named" -u 25 -s /sbin/nologin -r -d /etc/named named

2. Добавляем в группу named тех, кто имеет право запускать rndc.

3. Создаем директорию /etc/named:

 # mkdir /etc/named
 # chown root:named /etc/named
 # chmod 770 /etc/named

4. Кладем туда корневую зону (named.root)

5. Создаем локальную зону в файле loopback (127.0.0.1 тоже кто-то должен обрабатывать; почему localhost., а не доменное имя?):

 $TTL 1d
@ IN SOA каноническое-доменное-имя-сервера d-почтовый-адрес-администратора (
  2004012201 1d 1h 1w 1h )
  IN NS каноническое-доменное-имя-сервера
1 IN PTR localhost. 

6. Задаем права доступа к файлам в директории /etc/named

 # chown root:named /etc/named/*
 # chmod 640 /etc/named/*

7. Редактируем файл настройки /etc/named.conf (часть опций понадобятся для дальнейшего расширения функций сервера):

 acl "mynets" {
  192.168.0.0/24;
  ...
};
options {
  version "что-нибудь"; // скрыть номер версии, если Вы параноик
  directory "/etc/named";
  pid-file "named.pid";
  zone-statistics yes;
// разрешить запросы только своим клиентам
  allow-query { "mynets"; };
  allow-recursion { "mynets"; };
  allow-transfer { "mynets"; };
// укажем явно, на каких интерфейсах обслуживать запросы
  listen-on { 127.0.0.1; адрес-сервера; };
  interface-interval 0;
// с какого адреса выдавать запросы к другим серверам, AXFR/IXFR, NOTIFY
  query-source address адрес-сервера;
  transfer-source адрес-сервера;
  notify-source адрес-сервера;
// увы, окружающие серверы в большинстве своем не понимают "модных штучек"
  notify explicit;
  transfer-format one-answer;
  request-ixfr no;
// ограничения на потребление ресурсов
  max-cache-size 100M;
};
// весь вывод, включая отладку, на syslog:local1
// позволяет включать/выключать querylog (уровень сообщений info) 
//   и trace с нужным уровнем отладки (debug)
logging {
  channel debug_syslog {
    syslog local1;
    severity dynamic;
    print-category yes;
  };
  category default { debug_syslog; };
// lame-server в отдельный файл, поверьте - они вас достанут!
// размер файла и число версий - дело вкуса, можно и "versions 2 size 10k"
  channel lame-server {
    file "lamers.log" versions 99 size 10M;
    severity info;
    print-time yes;
  };
  category lame-servers { lame-server; };
};
zone "." in {
  type hint;
  file "named.root";
};
zone "0.0.127.in-addr.arpa" in {
  type master;
  file "loopback";
};

8. Проверяем синтаксис файла настройки: named-checkconf

9. Запускаем rndc-confgen и результат записываем в /etc/rndc.conf:

key "rndc-key" {
        algorithm hmac-md5;
        secret "очень секретная строчка";
};
options {
        default-key "rndc-key";
        default-server 127.0.0.1;
        default-port 953;
};

10. Текст, выданный rndc-confgen как комментарий, добавляем к /etc/named.conf:

key "rndc-key" {
      algorithm hmac-md5;
      secret "очень секретная строчка";
};
controls { // доступ только через loopback
      inet 127.0.0.1 port 953
              allow { 127.0.0.1; } keys { "rndc-key"; };
};

11. Устанавливаем права доступа:

 # chown root:named /etc/rndc.conf /etc/named.conf
 # chmod 0640 /etc/rndc.conf /etc/named.conf

11. Открываем локальный сетевой экран.

12. Тестовый запуск: named -u named

13. Заглядываем в журнал syslog, чтобы убедиться что все хорошо.

14. Попробуем найти локальный адрес:

# host 127.0.0.1 127.0.0.1

15. Запускаем shell на соседнем хосте и пробуем найти локальный адрес оттуда:

# host 127.0.0.1 адрес-сервера

16. Пробуем найти внешний адрес с соседнего хоста:

# host ya.ru адрес-сервера 

17. Обеспечиваем автоматический запуск сервера через /etc/rc.d

18. Настраиваем клиентов DNS в локальной сети.

19. Открываем внешние сетевые экраны.

20. Обеспечиваем выдачу адреса DNS сервера PPP-клиентам (у меня это делается через tacacs и извещаем остальных.

 

Первичный уполномоченный сервер для домена (primary, master)

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

Договариваемся с кем-либо о вторичном уполномоченном сервере для нашей зоны. Не рекомендуется иметь только один уполномоченный сервер для зоны. Многие регистраторы просто не делегируют вам зону, пока не убедятся в наличии для нее двух работоспособных DNS серверов в различных сетях. В принципе, если есть второй канал выхода в интернет и возможность установить второй DNS сервер (на отдельном компьютере), то можно обойтись своими ресурсами. В этом случае, необходимо одновременно установить вторичный уполномоченный сервер.

1. Создаем простейший файл зоны /etc/named/company.ru.master (права доступа к файлу – named:named 640):

$TTL 86400      ; 1 day
@ IN SOA ns d-почтовый-адрес-администратора (
           2004012201 1d 1h 1w 1h )
     NS ns
     NS каноническое-доменное-имя-вторичного-сервера
; кто-то должен обрабатывать почту, приходящую на наш домен
     MX 5 каноническое-имя-почтового-сервера
     MX 10 каноническое-имя-запасного-почтового-сервера
; если мы хотим, чтобы к WWW-серверу можно было 
; обратиться просто по имени домена
     A  адрес-HTTP-сервера
ns   A  адрес-нашего-сервера
; указание адреса вместо синонима ускорит доступ к сайту,
; но добавит забот при смене адреса
www  CNAME каноническое-имя-HTTP-сервера
; прочие сведения о домене (FTP, почта и т.д.)
...

2. Как видно, имя домена в файле зоны не присутствует. Это очень удобно, если необходимо обеспечить обслуживание сотни виртуальных доменов – файлы зон для них будут просто одинаковыми.

3. Добавляем в файл настройки /etc/named.conf информацию о вторичном сервере, если его возможности отличаются от описанных нами ранее в глобальных опциях, например:

server адрес-вторичного-сервера {
  transfer-format many-answers;
};

4. Добавляем в файл настройки /etc/named.conf описание зоны:

zone "company.ru" {
  type master;
  file "company.ru.master";
  allow-query { any; };
// если нет паранойи, то можно и так: allow-transfer { any; };
  allow-transfer { адрес-вторичного-сервера; };
// т.к. у нас в глобальных параметрах установлено: notify explicit,
// то необходимо явно указать список вторичных серверов, которые мы
// будем извещать об изменении зоны (если есть способные понять NOTIFY)
  also-notify { адрес-вторичного-сервера; };
};

5. Открываем внешние сетевые экраны для доступа к портам 53 (UDP и TCP).

6. Перезапускаем DNS сервер:

 # rndc reload 

7. Заглядываем в журнал syslog, чтобы убедиться что все хорошо.

8. Связываемся с администратором вторичного сервера, чтобы убедиться, что у него тоже все в порядке.

9. Обращаемся к регистратору за делегированием зоны (или изменяем информацию о серверах DNS для домена, если мы его переносили).

10. Регистратору может потребоваться некоторое время, чтобы проверить правильность работы указанных для домена серверов, после чего он делегирует домен и посылает извещение по e-mail.

11. Выждав некоторое время (необходимо для обновления БД регистратора и ее синхронизации с данными о зоне верхнего уровня), проверяем доступность информации о нашем домене снаружи:

 # host -t ns домен-какого-нибудь-нежадного-провайдера
 # host www.company.ru один-из-его-DNS-серверов

 

Вторичный уполномоченный сервер для домена (secondary, slave)

Данный сервер в дополнение к обслуживанию своих клиентов будет вторичным сервером для обратной зоны 195.161.72.0 и отвечать на внешние запросы для данной зоны. Настройка первичного сервера описана выше.

1. Добавляем в файл настройки /etc/named.conf информацию о первичном сервере, если его возможности отличаются от описанных нами ранее в глобальных опциях, например:

server адрес-первичного-сервера {
  request-ixfr yes;
  transfers 20;
};

2. Добавляем в файл настройки /etc/named.conf описание зоны:

zone "72.161.195.in-addr.arpa" in {
  type slave;
  file "72.161.195.in-addr.arpa.slave";
// вместо первичного сервера можно брать зону
// с другого вторичного сервера
  masters { адрес-уполномоченного-сервера; };
  allow-query { any; };
// если нет паранойи, то можно и так: allow-transfer { any; };
  allow-transfer { адреса-прочих-вторичных-серверов; };
};
}

3. Открываем внешние сетевые экраны для доступа к портам 53 (UDP и TCP).

4. Перезапускаем DNS сервер.

 # rndc reload

5. Заглядываем в журнал syslog, чтобы убедиться что все хорошо.

6. Просматриваем появившийся файл “72.161.195.in-addr.arpa.slave”

7. Обращаемся к своему LIR для того, чтобы он внес изменения в БД RIR (в большинстве случаев это будет БД RIPE) и делегировал подзону в 161.195.in-addr.arpa.

8. Выждав некоторое время, проверяем, что наш новый вторичный сервер появился в списке уполномоченных серверов.

 # host -t ns домен-какого-нибудь-нежадного-провайдера
 # host -t ns 72.161.195.in-addr.arpa. один-из-его-DNS-серверов

9. Так как мы устанавливали вторичный сервер, то для проверки работоспособности именно его нам потребуется “взгляд со стороны” (т.е. выполнять проверку необходимо с хоста, который не находится в нашем списке обслуживания рекурсивных запросов).

 

Поддомены без делегирования зоны

Добавить поддомен без делегирования прав его администрирования (т.е. без создания новой зоны) очень просто. Для этого в наш файл, описывающий зону, company.ru.master необходимо добавить следующие строки и перезапустить сервер (rndc reload; не забудьте предварительно увеличить серийный номер в SOA!):

$ORIGIN otdel.company.ru.
; если мы хотим, чтобы к WWW-серверу можно было 
; обратиться просто по имени домена
     A  адрес-HTTP-сервера
; кто-то должен обрабатывать почту, приходящую на наш домен
     MX 5 каноническое-имя-почтового-сервера
     MX 10 каноническое-имя-запасного-почтового-сервера
; указание адреса вместо синонима ускорит доступ к сайту,
; но добавит забот при смене адреса
www  CNAME каноническое-имя-HTTP-сервера
; прочие сведения о домене (FTP и т.д.)
...
$ORIGIN company.ru.

При необходимости создать много одинаковых поддоменов (отдельный виртуальный www-сайт для каждого отдела) можно сделать общий include-файл с именем standard-www-server.include

; если мы хотим, чтобы к WWW-серверу можно было 
; обратиться просто по имени домена
@    A    адрес-HTTP-сервера
; кто-то должен обрабатывать почту, приходящую на наш домен
     MX 5 каноническое-имя-почтового-сервера
     MX 10 каноническое-имя-запасного-почтового-сервера
; указание адреса вместо синонима ускорит доступ к сайту,
; но добавит забот при смене адреса
www  CNAME каноническое-имя-HTTP-сервера
; прочие сведения о домене (FTP и т.д.)
...

Теперь при необходимости создать поддомен для сайта очередного отдела достаточно добавить одну строку в наш файл, описывающий зону, company.ru.master и перезапустить сервер (rndc reload; не забудьте предварительно увеличить серийный номер в SOA!):

$INCLUDE standard-www-server.include otdelN.company.ru.

 

Создание поддоменов с делегированием зоны

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

Теперь в наш файл company.ru.master, описывающий базовую зону, добавляем строки, задающие первичный и вторичный серверы поддомена (здесь нет разницы между первичным и вторичным сервером):

superotdel NS каноническое-имя-сервера1-поддомена
           NS каноническое-имя-сервера2-поддомена

Для каждого канонического имени сервера, лежащего внутри делегируемого поддомена, необходимо явно задать его адрес для того, чтобы избежать проблемы “курицы и яйца” (чтобы обратиться к серверу поддомена необходимо знать его адрес, а чтобы узнать его адрес необходимо обратиться к серверу домена и т.д.). Информация об адресе узла поддомена не принадлежит базовой зоне и называется связующими записями (glue records):

каноническое-имя-сервера1-поддомена A адрес-сервера1-поддомена
каноническое-имя-сервера2-поддомена A адрес-сервера2-поддомена

Следует избегать лишних связующих записей (находящихся вне базовой зоны). В лучшем случае они будут проигнорированы. Необходимо следить за актуальностью связующих записей, иначе поддомен станет невидимым для внешнего мира.

 

Делегирование обратной зоны не по границе октета

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

Первое решение. Не делегировать подзону и вести общую обратную зону самостоятельно.

Второе решение. На каждый IP адрес в своей зоне добавить NS запись (или несколько записей, если подзона будет иметь несколько уполномоченных серверов):

$ORIGIN 72.161.195.in-addr.arpa.
128 NS имя-сервера-филиала
129 NS имя-сервера-филиала
...
143 NS имя-сервера-филиала

Директива $GENERATE позволяет уменьшить объем записей до

$ORIGIN 72.161.195.in-addr.arpa.
$GENERATE 128-143 $ NS имя-сервера-филиала

Файл /etc/named.conf сервера филиала должен иметь описание для каждой зоны вида:

zone "128.72.161.195.in-addr.arpa" {
  type master;
  file "128.72.161.195.in-addr.arpa.master";
}
zone "129.72.161.195.in-addr.arpa" {
  type master;
  file "129.72.161.195.in-addr.arpa.master";
}
...
zone "143.72.161.195.in-addr.arpa" {
  type master;
  file "143.72.161.195.in-addr.arpa.master";
}

При этом в каждом файле зоны 128.72.161.195.in-addr.arpa.master и остальных должна быть описана подзона для одного единственного адреса:

$TTL 86400      ; 1 day
@ IN SOA имя-сервера-филиала d-почтовый-адрес-администратора (
           2004012201 1d 1h 1w 1h )
     NS имя-сервера-филиала
     PTR имя-хоста-с-адресом-195.161.72.128

Третье решение (RFC 2317, BCP 20). На каждый IP адрес в своей зоне добавить CNAME запись, указывающую на соответствующий адрес во вспомогательном домене и NS запись (или несколько записей) для вспомогательного домена:

$ORIGIN 72.161.195.in-addr.arpa.
128     CNAME 128.128-143
129     CNAME 129.128-143
...
143     CNAME 143.128-143
128-143 NS имя-сервера-филиала

Директива $GENERATE позволяет уменьшить объем записей до

$ORIGIN 72.161.195.in-addr.arpa.
$GENERATE 128-143 $ CNAME $.128-143
128-143 NS имя-сервера-филиала

Файл /etc/named.conf сервера филиала должен иметь описание зоны вида:

zone "128-143.72.161.195.in-addr.arpa" {
  type master;
  file "128-143.72.161.195.in-addr.arpa.master";
}

Файл зоны 128-143.72.161.195.in-addr.arpa.master при этом должен содержать записи PTR для соответствующего интервала адресов:

$TTL 86400      ; 1 day
@ IN SOA имя-сервера-филиала d-почтовый-адрес-администратора (
           2004012201 1d 1h 1w 1h )
     NS имя-сервера-филиала
128  PTR имя-хоста-с-адресом-195.161.72.128
129  PTR имя-хоста-с-адресом-195.161.72.129
...
143  PTR имя-хоста-с-адресом-195.161.72.143

 

DNS в изолированной сети интернет

Если необходимо обеспечить работу DNS в сети интернет, изолированной от Интернет, то надо создать файл named.own.root, описывающий “нашу” корневую зону на “основном” DNS сервере:

$TTL 1d
@ IN SOA ns.company.ru. d-почтовый-адрес-администратора (
           2004012201 1d 1h 1w 1h )
     NS ns.company.ru.
; наш корневой сервер знает только о нашем домене и наших адресах
company.ru. NS ns.company.ru.
0.168.192.in-addr.arpa. NS ns.company.ru.
; адрес нашего корневого сервера
ns.company.ru. A 192.168.0.1

В /etc/named.conf необходимо заменить описание зоны корневых указателей (утверждение zone типа hint) на следующее:

zone "." {
  type master;
  file "named.own.root";
};

На остальных DNS серверах локальной сети необходимо заменить файл named.root следующим содержимым:

. 99999999 IN NS ns.company.ru.
ns.company.ru. 99999999 IN A 192.168.0.1

Можно даже использовать файл named_dump.db, предусмотрительно созданный ранее с помощью rndc dumpdb, в качестве корневой зоны при временной потере доступа ко всем корневым серверам (например, в результате атаки хакеров на них или при падении основного канала связи, используемого для DNS запросов).

 

Использование TSIG (transaction signatures)

Для защиты от искажений и подделок ответов сервера, передачи зоны и обновлений зоны (update) поддерживается использование расширения TSIG протокола DNS. Для защиты обмена между каждой парой участников необходимо создать отдельный общий ключ. Имя ключа имеет синтаксис доменного имени. Секретное значение ключа записывается в кодировке Base64. Можно придумать его самостоятельно, но рекомендуется использовать случайную 128-битную последовательность, создаваемую утилитой dnssec-keygen:

 # dnssec-keygen -a HMAC-MD5 -b 128 -n HOST <i>имя-ключа</i>

В результате работы утилиты в текущей директории создаются файлы, содержащие публичный (файл с суффиксом .key) и частный (файл с суффиксом .private) ключи. Имена файлов образуются из основы (печатается утилитой на stdout) и соответствующего суффикса. Для такого симметричного алгоритма как HMAC-MD5 оба файла содержат эквивалентные значения ключа в различных форматах: последнее поле в файле .key и строка с заголовком “Key:“ в файле .private.

Имя и значение ключа используется в утверждении
key файла настройки bind для описания ключа.

Если при описании удалённого сервера в утверждении server использовать предложение keys, то наш сервер будет подписывать указанным ключом все направляемые данному серверу обычные запросы и запросы на передачу зоны, а также проверять, что ответ подписан (не обязательно тем же самым ключом).

Предложение allow-transfer утверждения zone с использованием ключа в ACL позволяет ограничивать передачу зоны только теми клиентами, кто использовал соответствующий ключ для подписи запроса.

Предложения allow-update и update-policy позволяют ограничить динамические обновления.

Содержимое файлов и их производных следует хранить в секрете от посторонних лиц (права доступа, передача по SSH). Не забудьте о синхронизации времени, по умолчанию подпись действительна в течении 300 секунд.

 

Динамические изменения зоны

Расширение протокола DNS динамические изменения зоны) позволяет клиентам отправлять запросы на изменение записей о ресурсах (RR) первичному уполномоченному серверу непосредственно или с помощью вторичного уполномоченного сервера (предложение allow-update-forwarding в утверждении options или zone). Авторы не рекомендуют использовать передачу изменений через вторичные сервера. Серийный номер в SOA увеличивается BIND 9.2.3 при каждом изменении.

Нельзя редактировать файл зоны вручную одновременно с использованием механизма динамических изменений. Динамические изменения записывается в отдельный журнал для каждой зоны (имя файла – имя зоны с добавлением суффикса .jnl). Журнал сливается с файлом зоны через какой-то промежуток времени или при достижении максимального размера, задаваемого предложением max-journal-size в утверждении options или zone.

Сервер может проверять право клиента на изменение зоны по его IP адресу (не рекомендуется) или при помощи механизма TSIG – см. описание предложений allow-update и update-policy утверждения zone.

Утилита nsupdate позволяет сформировать пакет изменений и отослать его первичному уполномоченному серверу (имя сервера извлекается из SOA зоны). Пакет формируется на основе команд читаемых с stdin или из файла (имя файла задаётся в качестве параметра):

• ; … – (комментарий);
• server имя-сервера [порт];
• local IP-адрес [порт];
• zone имя-зоны;
• key имя-ключа значение-ключа – (TSIG);
• send – (послать сформированный пакет серверу);
• пустая строка – (послать сформированный пакет серверу);
• show – (показать текущий пакет);
• prereq yxrrset доменное-имя [класс] тип-записи значение-записи-ресурса – (предварительное условие – указанное доменное имя имеет записи ресурсов указанного типа с заданными значениями);
• prereq yxrrset доменное-имя [класс] тип-записи – (предварительное условие – указанное доменное имя имеет хотя бы одну запись ресурсов указанного типа);
• prereq nxrrset доменное-имя [класс] тип-записи – (предварительное условие – указанное доменное имя не имеет ни одной записи ресурса указанного типа);
• prereq yxdomain доменное-имя – (предварительное условие – указанное доменное имя имеет хотя бы одну запись ресурса);
• prereq nxdomain доменное-имя – (предварительное условие – указанное доменное имя не имеет ни одной записи ресурса);
• update delete доменное-имя [класс] тип-записи значение-записи-ресурса – (удалить запись ресурса с заданным значением из RRset указанного типа для данного доменного имени);
• update delete доменное-имя [класс] тип-записи – (удалить набор записей ресурса указанного типа для данного доменного имени);
• update delete доменное-имя – (удалить все наборы ресурсов, относящиеся к указанному доменному имени);
• update add доменное-имя TTL [класс] тип-записи значение-записи-ресурса – (добавить запись ресурса).

Ключи утилиты:

• -v – (использовать TCP вместо UDP, рекомендуется);
• -d – (отладочная трассировка);
• -y имя-ключа:значение-ключа – (ключ TSIG для подписи сообщений; не рекомендую – может быть прочитан командой ps и т.п.);
• -k имя-файла .private – (ключ TSIG для подписи сообщений извлекается из файла .private, созданного утилитой dnssec-keygen).

_________________
Оригинал статьи на сайте http://www.bog.pp.ru/