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

Автор:  Уваров А.С. 31.10.2022Время чтения: 8 мин Debian и Ubuntu Server

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

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

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

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

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

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

1apt install bind9

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

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

1directory "/var/cache/bind";

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

1listen-on port 53 { 127.0.0.1; 192.168.72.8; };
2 allow-query { 127.0.0.0/8; 192.168.72.0/24; };
3 allow-recursion { 127.0.0.0/8; 192.168.72.0/24; };
4 allow-transfer { none; };
5 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1$TTL 86400 ;
2@ IN SOA dns-1.interface31.lab. root.interface31.lab. (
3         2022103006 ; Serial
4         600 ; Refresh
5         3600 ; Retry
6         1w ; Expire
7         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-сервера, в качестве значений используем доменные имена:

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

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

1@       IN A 192.168.72.1
2chr72   IN A 192.168.72.1
3dns-1   IN A 192.168.72.8
4dns-2   IN A 192.168.72.9
5pve7    IN A 192.168.72.7
6proxmox IN CNAME pve7

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

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

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

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

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

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

1touch /var/lib/bind/db.192.168.72

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

 1$TTL 86400 ;
 2@ IN SOA dns-1.interface31.lab. root.interface31.lab. (
 3         2022103005 ; Serial
 4         600 ; Refresh
 5         3600 ; Retry
 6         1w ; Expire
 7         360 ) ; Negative Cache TTL
 8
 9@ IN NS dns-1.interface31.lab.
10@ IN NS dns-2.interface31.lab.

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

18 IN PTR dns-1.interface31.lab.
29 IN PTR dns-2.interface31.lab.
37 IN PTR pve7.interface31.lab.
41 IN PTR chr72.interface31.lab.

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

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

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

1named-checkconf

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

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

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

1systemctl restart named
2systemctl status named

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

1nslookup pve7.interface31.lab 192.168.72.8

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

1nslookup 192.168.72.7 192.168.72.8

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

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

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

1apt install bind9

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

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

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

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

 1zone "interface31.lab" {
 2     type slave;
 3     file "db.interface31.lab";
 4     masters { 192.168.72.8; };
 5};
 6
 7zone "72.168.192.in-addr.arpa" {
 8     type slave;
 9     file "db.192.168.72";
10     masters { 192.168.72.8; };
11};

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

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

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

1named-checkconf

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

1systemctl restart named

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

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Поддержи проект!

Или подпишись на наш Телеграм-канал: Подпишись на наш Telegram-канал

Bind 9 Debian DNS Failover High availability Linux Ubuntu Server Сетевые технологии