Настройка DNS-сервера BIND

Материал из Xgu.ru

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

Автор: Сергей Черепенин
Короткий URL: bind

На этой странице описывается процедура инсталляции и настройки DNS-сервера BIND для работы в режиме кэширующего и авторитетного сервера доменных имён.

Содержание

[править] Инсталляция DNS-сервера BIND

Установка сервера в Debian / Ubuntu:

[править] Начальное конфигурирование DNS-сервера

После установки сервера необходимо указать некоторые параметры для работы сервера. Это делается путем редактирования определенных директив в файле /etc/bind/named.conf.options:

Директива directory указывает на расположение в дереве каталогов временных файлов сервера.

Директива forwarders — на какие серверы пересылать запрос, если наш сервер сам не в состоянии определить имя или IP-адрес запроса клиентов.

Директива listen-on указывает на каких интерфейсах вести прослушивание 53 порта.

[править] Запуск DNS-сервера

После редактирования этого файла необходимо рестартовать сервер:

[править] Настройка DNS-сервера для работы в режиме авторитетного сервера

Далее необходимо указать в основном конфигурационном файле сервера /etc/bind/named.conf.local имена файлов, в которых мы далее опишем зоны для прямого и обратного преобразований. Добавляем следующие строки в этот файл:

Файл /etc/bind/db.unix.nt служит для описания зоны прямого преобразования, а файл /etc/bind/db.rev_unix.nt — для обратного

Содержание файла /etc/bind/db.unix.nt:

Содержание файла /etc/bind/db.rev_unix.nt:

Примечание: для быстрого описания всей зоны (254 хоста) можно дать команду в vim:

— для прямой зоны:

— для обратной зоны:

Другой вариант — использование директивы $GENERATE

для реверсной зоны и аналогично для прямой зоны

[править] Настройка резолвера DNS

Резолвер (resolver) — клиентская библиотека DNS, которая используется всеми программами Unix/Linux, которым нужен доступ к доменной системе имён.

Итак, прямое и обратное преобразование работает. На этом настройка DNS сервера завершена. Необходимо только указать операционной системе использовать только что сконфигурированный сервер. Делается это через файл /etc/resolv.conf:

[править] Клиенты DNS. Программа dig

Эти темы не раскрыты: Клиенты DNS. Программа dig

dig — программа, предназначенная для получения информации из DNS. Пришла на смену устаревшей программе nslookup.

Пример использования команды dig:

[править] Обратное преобразование имён

Эти темы не раскрыты: Обратное преобразование имён.

[править] DNS и DHCP: Динамическое обновление

Эти темы не раскрыты: Динамическое обновление.

[править] BIND в качестве DNS в AD

Эти темы не раскрыты: Динамическое обновление.

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

DNS сервер BIND

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

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

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

Файл настройки 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-notifyexplicit – посылать только серверам из списка 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_addrport 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 устанавливает опции, специфические для указанной зоны. Формат утверждения следующий:

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

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

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

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

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

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

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

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

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

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

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

В предложении 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 тоже надо просматривать регулярно). По умолчанию принимается следующая настройка записи в журнал:

Количество статистической информации, собираемой 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. Предусматриваются следующие типы утверждений:

Утилита 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 позволяет менять параметры соединения с сервером с помощью ключей:

Если запустить 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 следующего вида (реальный файл из дистрибутива будет содержать множество проверок):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В результате работы утилиты в текущей директории создаются файлы, содержащие публичный (файл с суффиксом .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).