Настраиваем отказоустойчивый DNS-сервер на базе BIND 9

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

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

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

BIND 9 - это полнофункциональный открытый DNS-сервер, имеющий широкое распространение, 10 из 13 корневых DNS-серверов работают именно на BIND. В данной статье мы будем рассматривать установку BIND в среде Debian или Ubuntu, все действия, если не указано иного, выполняются с правами суперпользователя (root). Также предполагается, что читатель имеет представление о назначении DNS-сервера и основных типах DNS-записей.

Установка и настройка BIND 9 на первичном сервере

Установка BIND и всех необходимых пакетов производится одной командой:

apt install bind9

При этом обратите внимание, что несмотря на то, что имя пакета bind9 установленная служба имеет название named.

Затем откроем файл /etc/bind/named.conf.options и после строки:

directory "/var/cache/bind";

Добавим следующие настройки:

listen-on port 53 { 127.0.0.1; 192.168.72.8; };
 allow-query { 127.0.0.0/8; 192.168.72.0/24; };
 allow-recursion { 127.0.0.0/8; 192.168.72.0/24; };
 allow-transfer { none; };
 forwarders { 8.8.8.8; 8.8.4.4; };

Разберем их подробнее:

listen-on port 53 - адреса на которых сервер будет принимать запросы, где 192.168.72.8 - адрес самого сервера
allow-query - адреса сетей из которых принимаем запросы, указываем подсеть localhost и диапазон локальной сети
allow-recursion - разрешаем рекурсивные запросы для localhost и локальной сети
allow-transfer - кому можно предавать данные DNS-зон, по умолчанию никому
forwarders - сервера пересылки, которым мы будем передавать запросы, которые не сможем разрешить самостоятельно, указываем любые внешние DNS

После чего приведем к следующему виду еще две опции:

dnssec-validation no;
 listen-on-v6 { none; };

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

zone "interface31.lab" {
     type master;
     file "/var/lib/bind/db.interface31.lab"; 
     allow-transfer { 192.168.72.9; };
};

Назначение параметров:

zone - наименование зоны, которую будет обслуживать сервер, задается в виде доменного имени, в нашем случае interface31.lab
type - тип зоны, в нашем случае - master - первичная
file - файл с данными зоны, вы можете выбрать произвольное наименование, но в Debian принято соглашение называть эти файлы как db.имя_зоны, а хранить их в /var/lib/bind.
allow-transfer - узел, которому разрешается передавать данные зоны, указываем адрес нашего вторичного DNS-сервера

Затем добавим туда же описание обратной зоны:

zone "72.168.192.in-addr.arpa" {
     type master;
     file "/var/lib/bind/db.192.168.72";
     allow-transfer { 192.168.72.9; };
};

Название обратной зоны записывается как адрес сети без последнего октета (для сетей /24) наоборот и дополняется in-addr.arpa. Остальные параметры те же.

Настройка прямой зоны

Прямая зона отвечает за сопоставление доменных имен IP-адресам, при запросе к прямой зоне мы указываем доменное имя и получаем в ответ связанный с ним IP-адрес.

Создадим указанный нами в описании зоны файл:

touch /var/lib/bind/db.interface31.lab

И начнем его заполнять, прежде всего внесем начальная запись зоны - SOA:

$TTL 86400 ;
@ IN SOA dns-1.interface31.lab. root.interface31.lab. (
         2022103006 ; Serial
         600 ; Refresh
         3600 ; Retry
         1w ; Expire
         360 ) ; Negative Cache TTL

Что означают эти записи?

TTL - время жизни DNS-записи, в нашем случае сутки, именно на это время клиент может поместить ее в собственный кеш, по истечении TTL клиент обязан запросить запись заново

@ IN SOA - основная запись домена, указывает его корневой DNS-сервер - dns-1.interface31.lab. и адрес ее администратора root.interface31.lab. (который следует понимать, как root@interface31.lab). Символ @ в начале строки указывает на текущий домен

Обратите внимание, что доменные имена внутри файлов зоны должны указываться в абсолютной форме записи, т.е. с точкой на конце. В противном случае окончание домена будет дополнено значением текущего. Т.е. вместо dns-1.interface31.lab вы получите dns-1.interface31.lab.interface31.lab

Ниже идут записи отвечающие за синхронизацию зоны со вторичными серверами:

Serial - серийный номер зоны, при каждом изменении данных мы должны увеличивать серийный номер, по его изменению вторичные сервера понимают, что произошли изменения и начинают синхронизацию. Широко применяется следующий алгоритм формирования серийного номера: ГГГГ-ММ-ДД плюс две цифры указывающие на номер итерации, если в одну и ту же дату вносится несколько изменений.
Refresh - период обновления данных вторичными серверами, по истечении данного времени они повторно запрашивают у основного сервера SOA-запись и анализируют серийный номер.
Retry - периодичность повторного обращения к основному серверу, если предыдущая попытка завершилась неудачей
Expire - максимальное время жизни зоны на вторичных серверах при отсутствии синхронизации с основным, по истечении этого времени вторичный сервер перестает обслуживать запросы
Negative Cache TTL - время жизни негативного кеша или минимальное время жизни записи. Применяется для кеширования неудачного результата запроса со стороны клиента, например, обращение к несуществующему доменному имени.

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

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

@ IN NS dns-1.interface31.lab.
@ IN NS dns-2.interface31.lab.

Под ними уже располагаем записи относящиеся непосредственно к узлам, например:

@       IN A 192.168.72.1
chr72   IN A 192.168.72.1
dns-1   IN A 192.168.72.8
dns-2   IN A 192.168.72.9
pve7    IN A 192.168.72.7
proxmox IN CNAME pve7

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

Кроме A - записей зона может содержать и другие, все зависит от текущих потребностей. Например, мы добавили запись псевдонима - CNAME, которая указывает на то, что при запросе proxmox.interface31.lab нужно вернуть результат для имени pve7.interface31.lab. Чем это удобно? Тем что мы можем присвоить сетевым службам красивые имена, которые не будут привязаны к определенным узлам. Скажем переместили службу с srv-1 на srv-2 - просто поменяли CNAME.

Заканчиваться файл зоны должен пустой строкой.

Настройка обратной зоны

Обратная зона предназначена для обратного преобразования, с ее помощью мы можем по IP-адресу узнать доменное имя узла. Для повседневной работы обратная зона обычно не требуется, и многие администраторы ее не создают, но при ее отсутствии могут возникнуть проблемы у многих сетевых сервисов, чаще всего неявные и неочевидные для начинающих, поэтому мы рекомендуем всегда сразу создавать обратную зону.

Точно также создадим файл зоны:

touch /var/lib/bind/db.192.168.72

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

$TTL 86400 ;
@ IN SOA dns-1.interface31.lab. root.interface31.lab. (
         2022103005 ; Serial
         600 ; Refresh
         3600 ; Retry
         1w ; Expire
         360 ) ; Negative Cache TTL

@ IN NS dns-1.interface31.lab.
@ IN NS dns-2.interface31.lab.

Затем начнем заполнять его записями, для показанной выше прямой зоны обратная будет выглядеть так:

8 IN PTR dns-1.interface31.lab.
9 IN PTR dns-2.interface31.lab.
7 IN PTR pve7.interface31.lab.
1 IN PTR chr72.interface31.lab.

Что обозначают эти записи? Начнем с того, что если имя узла указано без точки, то оно дополняется именем текущего домена, поэтому для указанной нами в записи цифры 8 это будет 8.72.168.192.in-addr.arpa, т.е. обратная запись для узла с адресом 192.168.72.8. Также обратите внимание, что доменные имена узлов следует указывать полностью, с точкой на конце.

Проверка работы первичного DNS-сервера

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

named-checkconf

Затем проверим зоны, для этого указываем их наименования и пути к файлам данных:

named-checkzone interface31.lab /var/lib/bind/db.interface31.lab
named-checkzone 72.168.192.in-addr.arpa /var/lib/bind/db.192.168.72

Если ошибок не зафиксировано, то перезапускаем службу и проверяем ее работу:

systemctl restart named
systemctl status named

Теперь можно попробовать направить запрос, начнем с прямого:

nslookup pve7.interface31.lab 192.168.72.8

Затем проверим обратный

nslookup 192.168.72.7 192.168.72.8

Чтобы запрос был направлен именно нашему серверу мы явно указываем его адрес вторым параметром команды.

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

Установка и настройка BIND 9 на вторичном сервере

Точно также установим пакет на второй сервер:

apt install bind9

И сразу перейдем к /etc/bind/named.conf.options, настройки которого полностью аналогичны первичному серверу, за исключением строки:

listen-on port 53 { 127.0.0.1; 192.168.72.9; };

В которой следует указать IP-адрес второго сервера, у нас это 192.168.72.9.

Теперь откроем /etc/bind/named.conf.local и пропишем зоны:

zone "interface31.lab" {
     type slave;
     file "db.interface31.lab"; 
     masters { 192.168.72.8; };
};

zone "72.168.192.in-addr.arpa" {
     type slave;
     file "db.192.168.72"; 
     masters { 192.168.72.8; };
};

Назначение параметров:

type - тип зоны, в нашем случае вторичная - slave
file - имя файла зоны, указываем без путей, файлы вторичных зон хранятся в /var/cache/bind
masters - адрес нашего первичного сервера с которого вторичный будет забирать изменения

После чего проверяем правильность конфигурации:

named-checkconf

И перезапускаем сервер:

systemctl restart named

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

Записки IT специалиста