Настройка 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 под Windows для разблокировки ЖЖ и Гугла

Установка BIND

• Скачайте bind для windows по ссылке — ftp://ftp.isc.org/isc/bind9/9.8.1/BIND9.8.1.zip
• Извлеките содержимое архива в заранее созданную пустую папку и запустите BINDInstall.exe
• Установщик спросит в какую папку установить программу. В своем случае я выбрал «C:\bind». Далее придумайте логин и пароль для сервиса.

Настройка

Сохраните их в указанных папках С:\bind\etc\named.conf C:\bind\zones\db.livejournal.com.txt C:\bind\zones\db.googleusercontent.com.txt

• Запустите командную строку (Пуск — Выполнить — cmd) и выполните по очереди следующие команды

cd С:\bind\bin
rndc-confgen -a
rndc-confgen > ..\etc\rndc.conf
В файле С:\bind\etc\named.conf поменяйте значение поля secret на аналогичное из файла C:\bind\etc\rndc.key

Запуск

• Пуск — Выполнить — services.msc
• Найдите службу ISC Bind и запустите ее

Проверка

• Пропишите в свойствах сетевой карты dns сервер 127.0.0.1
• Наберите в командной строке nslookup ya.ru 127.0.0.1
• Для проверки ЖЖ наберите nslookup megakhuimyak.livejournal.com 127.0.0.1

Если ответ как на картинке значит все ОК

PS
Для того что бы перезапускать bind после правки в конфигурации остановите службу ISC Bind? выполните в командной строке c:\bind\bin\rndc reload и запустите службу снова

HOWTO DNS сервер BIND

Общие сведения

Named – это демон, входящий в состав пакета bind9 и являющийся сервером доменных имен. Демон named может реализовывать функции серверов любого типа: master, slave, cache. На приведенной схеме я постарался максимально прозрачно отобразить основной принцип работы DNS сервера BIND. Бинарник, который выполняет основную работу, расположен в /usr/sbin/named. Он берет настройки из основного конфигурационного файла, который называется named.conf и расположен в каталоге /etc/bind. В основном конфиге описывается рабочий каталог асервера, зачастую это каталог /var/cache/bind, в котором лежат файлы описания зон и другие служебные файлы. Соответствиеназвания зоны и файла описания зоны задает раздел zone с параметром file. Раздел zoneтак же задает тип ответственности данного сервера за зону (master, slave и др.), а так же определяет особые параметры для текущей зоны (например, на каком интерфейсе обрабатывать запросы для текущей зоны). В файлах описания зон содержатся параметры зон и записи ресурсов (пути, указанные в данном абзаце могут отличаться, это зависит от дистрибутива Linux или параметров сборки сервера из исходников).

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

Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в восьмой и девятой версиях BIND. Учитывая, что я рассчитываю на установку нового DNS сервера, а старую версию смысла ставить не вижу, посему буду рассматривать конфиг новой версии.

Исходные данные

Для корректной работы DNS нем необходимо иметь настроенную сеть. DNS в текущей статье будет настроен на дистрибутиве FreeBSD, Конфиг сети стенда следующий:

где XXX.XXX.XXX.XXX – внешний интерфейс (подсеть, выделенная провайдером). Настраиваемая зона будет иметь имя disnetern.lan.

Установка BIND9

Для работы DNS сервера необходимо установить пакет bind9 (в некоторых дистрибутивах – bind). Как отмечено на схеме – основным конфигурационным файлом BIND является файл named.conf (данный файл может быть размещен в каталоге /usr/local/etc/named/ ).

Параметры (синтаксис) named.conf

Синтаксис файла named.conf придерживается следующих правил:

IP-адреса – список IP должен быть разделен символом “;” , возможно указывать подсеть в формате 192.168.1.1/24 или 192.168.1.1/255.255.255.0, (для исключения IP перед ним нужно поставить знак !), возможно указывать имена “any”, “none”, “localhost” в двойных кавычках.

Комментарии – строки начинающиеся на #, // и заключенные в /* и */ считаются комментариями.

В файлах описания зон – символ @ является “переменной” хранящей имя зоны, указанной в конфигурационном файле named.conf или в директиве @ $ORIGIN текущего описания зоны.

Каждая завершенная строка параметров должна завершаться символом ; .

Раздел Acl

Acl (access control list) – позволяет задать именованный список сетей. Формат раздела: acl “имя_сети” ;

Раздел Options

Раздел Options задает глобальные параметры конфигурационного файла, управляющие всеми зонами. Данный раздел имеет формат: options <операторы_раздела_Options>;. Options может быть “вложен” в раздел Zone, при этом он переопределяет глобальные параметры. Часто используемые операторы options:

• allow-query <список_ip> – Разрешает ответы на запросы только из список_ip. При отсутствии – сервер отвечает на все запросы.
• allow-recursion <список_ip> – На запросы из список_ip будут выполняться рекурсивные запросы. Для остальных – итеративные. Если не задан параметр, то сервер выполняет рекурсивные запросы для всех сетей.
• allow-transfer <список_ip> – Указывает список серверов, которым разрешено брать зону с сервера (в основном тут указывают slave сервера)
• directory /path/to/work/dir – указывает абсолютный путь к рабочему каталогу сервера. Этот оператор допустим только в разделе options.
• forwarders <ip порт, ip порт...> – указывает адреса хостов и если нужно порты, куда переадресовывать запросы (обычно тут указываются DNS провайдеров ISP).
• forward ONLY или forward FIRST – параметр first указывает, DNS-серверу пытаться разрешать имена с помощью DNS-серверов, указанных в параметре forwarders, и лишь в случае, если разрешить имя с помощью данных серверов не удалось, то будет осуществлять попытки разрешения имени самостоятельно.
• notify YES|NO – YES – уведомлять slave сервера об изменениях в зоне, NO – не уведомлять.
• recursion YES|NO – YES – выполнять рекурсивные запросы, если просит клиент, NO – не выполнять (только итеративные запросы). Если ответ найден в кэше, то возвращается из кэша. (может использоваться только в разделе Options)

Раздел Zone

Определяет описание зон(ы). Формат раздела: zone <операторы_раздела_zone>;Операторы, которые наиболее часто используются:

• allow-update <список_ip> – указывает системы, которым разрешено динамически обновлять данную зону.
• file “имя_файла” – указывает путь файла параметров зоны (должен быть расположен в каталоге, определенном в разделе options оператором directory)
• masters <список_ip> -указывает список мастер-серверов. (допустим только в подчиненных зонах)
• type “тип_зоны” – указывает тип зоны, описываемой в текущем разделе,тип_зоны может принимать следующие значения:
  • forward – указывает зону переадресации, которая переадресовывает запросы, пришедшие в эту зону.
  • hint – указывает вспомогательную зону (данный тип содержит информацию о корневых серверах, к которым сервер будет обращаться в случае невозможности найти ответ в кэше)
  • master – указывает работать в качестве мастер сервера для текущей зоны.
  • slave – указывает работать в качестве подчиненного сервера для текущей зоны.

Дополнительные параметры конфигурации

Значения времени в файлах зон по умолчанию указывается в секундах, если за ними не стоит одна из следующих букв: S – секунды, M – минуты, H- часы, D – дни, W – недели. Соответственно, запись 2h20m5s будет иметь значение 2 часа 20 минут 5 секунд и соответствовать 8405 секунд.

Любое имя хоста/записи, не оканчивающиеся точкой считается неFQDN именем и будет дополнено именем текущей зоны. Например, запись domen в файле зоны examle.com будет развернуто в FQDN-имя domen.examle.com. .

В конфигурационных файлах BIND могут применяться следующие директивы:

• $TTL – определяет TTL по-умолчанию для всех записей в текущей зоне.
• $ORIGIN – изменяет имя зоны с указанного в файле named.conf. При этом, область действия данной директивы не распространяется “выше” (то есть если файл включен директивой $INCLUDE, то область действия$ORIGN не распространяется на родительский)
• $INCLUDE – включает указанный файл как часть файла зоны.

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

Если в имени ресурсной записи встречается символ “*”, то это он означает что вместо него можно подразумевать любую разрешенную последовательность символов. Такую запись называют “wildcard запись“. Однако, символ “*” не может быть использован где угодно. Это может быть только первый символ в поле Name текущего домена, отделенный от остальных символом “.”

Настройка кэширующего DNS сервера

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

Для того, чтобы BIND работал в качестве кэширующего сервера, необходимо иметь конфигурационные файлы заполненные необходимой информацией:

• named.conf;
• описание серверов корневой зоны (зона типа hint);
• описание зоны 127.in-addr.arpa.

В данном примере приведен кэширующий DNS сервер, обрабатывающий запросы из списка сетей lan, в которую входит только одна локальная сеть 192.168.1.1/24 и петлевой интерфейс. При необходимости можно включить туда и другие сети. После определения списка сетей в директиве acl, в любом месте конфига можно будет ссылаться на этот список по имени (в нашем примере имя – lan), что, собственно и сделано в разделе options. Большинство параметров я прокомментировал, но отдельного внимания требует раздел, описывающий зону корневых серверов. В параметре file задан относительный путь к файлу описания корневых серверов (путь, относительно рабочего каталога сервера). За обновлениями данного файла необходимо следить, хотя он обновляется довольно редко (откуда брать обновленный файл я писал в теории DNS). Как вы заметили, имеется так же две записи для зоны localhost и две записи обратных зон для броадкаст доменов. Назначение этих зон состоит в том, чтобы избежать трансляции случайных запросов имен соответствующих IP-адресов на серверы, обслуживающие корневую зону.

Чтобы не вносить неразбериху в куче конфигурационных файлов, в статье я привожу примеры на основе единого конфигурационного файла. На самом деле, в последних версиях Debian (и других дистрибутивах Linux), файл named.conf выглядит следующим образом:

То есть основной файл не содержит конфигураций, а включает в себя более узко специализированные файлы, которые отвечают за свои задачи, например named.conf.options – содержит глобальные параметры конфигурации, named.conf.default-zones – содержит описание localhost и broadcast зон, а named.conf.local содержит описания зон, за которые отвечает данный сервер.

Первая строка задает параметр $TTL, который определяет время кеширования положительных ответов (ответ в виде найденного IP-адреса). Здесь и далее, время может задаваться в секундах или с помощью сокращений: m — минуты, h — часы, d — дни, w — недели.

В записи SOA указывается primary NS для домена и e-mail контактного лица. В скобках, по порядку:

1. Serial — Серийный номер. Каждый раз при изменении каких-либо данных его нужно обязательно менять. Когда меняется серийный номер, зона обновляется на всех серверах. Используйте следующий формат: ГГГГММДДнн (год, месяц, день, нн — порядковый номер изменения за день). Если вы уже второй раз за день вносите измения в файл зоны, укажите “нн” равным 01, если третий — 02, и т.д.
2. Refresh — интервал, через который slave сервера должны обращаться к primary серверу и проверять обновление зоны.
3. Retry — если slave серверу не удалось обратится к primary серверу, через это время он должен повторить свой запрос.
4. Expiry — если в течении этого времени slave сервер так и не смог обновить зону с primary сервера, то slave должен прекратить обслуживать эту зону.
5. TTL — время кеширования отрицательных ответов (ответ “домен невозможно разрешить в IP адрес”)

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

Секция MX описывает почтовые шлюзы (обычно один), на которые будет доставляться вся почта этого домена. Для каждого шлюза устанавливается приоритет (по умолчанию — 10). Обычно имя домена почтового шлюза выглядит так: mx.example.com.

В секции A указываются субдомены (A) и синонимы (CNAME). В примере домен example.com указывает на IP адрес 192.168.1.1, а домен www.example.comявляется синонимом example.com.

• Если вы указываете полное имя домена, пишите в его конце точку.
• Записи NS, MX и A для основного домена (не субдомена) не должны начинаться с начала строки.
• Если почтовый шлюз принадлежит этому же домену, не забывайте указывать его в секции A.

Проверить файл зоны на ошибки можно с помощью команды:

Далее, хочу обратить внимание на наличие файлов зон в каталоге, указанном в разделе options в параметре directory с именами, соответствующими параметрам file в разделах, описывающих зоны:

Рассматривать файлы “петлевых” и бродкастовых зон не вижу смысла, т.к. после установки пакета bind настройки заданные по умолчанию в данных файлах вполне приемлемы. Далее, при организации мастер сервера мы рассмотрим пример описания файла зоны. Хочу обратить внимание, что мы настраиваем кэширующий сервер, а определяем мы его и как master для некоторых из зон. В нашем случае “кэширующий” говорит о том, что наш сервер не поддерживает ни одну из реально существующих зон, т.е. ему не делегировано прав на такое обслуживание.

На этом настройка кэширующего DNS завершена. Все запросы, которые попадают в кэш DNS сервера он хранит в оперативной памяти компьютера и при перезапуске демона эти данные обнуляются. Для проверки работы кэша можно выполнить команду nslookup mail.ru example.com., если в ответе содержится строка Non-authoritative answer, то адрес пришел из кэша, а так же если выполнить dig www.ru. (или другой домен, которого еще нет в кэше) и через некоторое время повторить команду, то время ответа должно быть гораздо меньше.

Главный (master) сервер зоны

Основной конфиг содержит следующие настройки:

Давайте кратко разберем конфигурационный файл и настройки master сервера: мы настраиваем мастер сервер для зоны example.com. . Согласно конфига, наш BIND имеет рабочий каталог /var/cache/bind, сервер отвечает на запросы со всех интерфейсов (allow-query ;), рекурсивные запросы обрабатывает как итеративные (recursion no), является мастер-сервером для зоны example.com и локальных служебных зон (type master). При этом, если необходимо разрешить кэширование (то есть рекурсивные запросы) для локальной сети, то необходимо раскомментировать параметры forwarders и allow-recursion и закомментировать recursion no;.

Так же, для примера, я привел возможности BINDлогировать все происходящее при работе сервера (можно для этой цели использовать syslog). В разделе logging задаются 2 параметра channel (можно и больше двух – на ваше усмотрение), эти параметры дословно можно назвать “канал” записи. Каждый канал определяет имя канала и настройки параметров записи (что записывать, а что – нет и куда писать). Директива category задает какую категорию сообщений в какой канал отправлять. Исходя из этого, мы имеем: запись стандартной информации в канал misc, а приходящие запросы посылаются в канал query. При этом, если файлы журнала достигают 4Мб (size 4m), он переименовывается добавлением к имени .1 и начинается запись в новый журнал, числа в конце других журналов увеличиваются. Журналы с номером, более указанного в version (в нашем случае 4) удаляются (Управлять ротацией логов можно так же с помощью logrotate). Параметры print* определяют заносить ли в журнал время появления, важность и категорию информации. Более подробно про настройки раздела logging можно почитать в man (5) named.conf.

Отдельно хочется описать параметр allow-transfer < 10.0.0.191; >;. Данный параметр описывает серверы, которым разрешено скачивать копию зоны – т.н. slave серверА. В следующем примере мы разберем настройку slave DNS.

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

Давайте далее рассмотрим наш файл описания зоны example.com.:

а так же в домене in-addr.arpa.

Наша сеть небольшая, предполагается, что в сети совсем мало машин. Все сервисы сети размещены на одном хосте example.com., поэтому и master DNS (ns.example.com.) и почтовый сервер (mx.example.com.) указывает на одну машину (10.0.0.152).

Вторичный (secondary, slave) авторитетный сервер зоны

Основная функция slave сервера – автоматическая синхронизация описания зоны с master сервером. Данная задача регламентируется документом RFC 1034 в разделе 4.3.5. Согласно данному документу обмен данными между серверами рекомендовано производить по протоколу TCP, посредством запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).

Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.

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

Получение зоны прошло успешно. Далее, для настройки подчиненного сервера, алгоритм следующий:

1. Скопироватьконфигурационный файл named.conf с master сервера;
2. Заменитьпараметр type master на type slave в тех зонах, для которых он будет вторичным;
3. Параметр allow-transfer < 10.0.0.191; >;заменить на masters < 10.0.0.152;>; в тех зонах, для которых он будет вторичным;
4. Удалить зоны, которые не будет обслуживать текущий сервер, в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
5. Создать каталоги для логов, как в предыдущем примере.

Итого, мы получаем конфиг slave сервера:

после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в каталоге:

Резюме

В текущей статье описана настройка основных конфигураций DNS сервера BIND. Целью статьи было – дать представление о работе сервера BIND в UNIX. Практически не затронуты вопросы безопасности ДНС и мало затронуты такие специфичные настройки, как работа сервера в пограничном режиме, когда в разные сети отдается разная информация о зоне(нах). Для более глубокого освоения ниже есть список дополнительных источников, в которых удастся получить нужную информацию.