Настраиваем отказоустойчивый DNS-сервер на базе BIND 9
DNS-сервер относится к наиболее критичным элементам сетевой инфраструктуры, так как именно на него возлагается задача разрешения доменных имен, без которой трудно представить работу любой сети. Поэтому важно не допускать перебоев в обслуживании клиентов, а справиться с этой задачей нам поможет отказоустойчивая конфигурация из нескольких DNS-серверов. В данной статье мы рассмотрим, как создать собственную инфраструктуру DNS при помощи полнофункционального и открытого DNS-сервера BIND 9.
Прежде всего коснемся понятия отказоустойчивости, многие неправильно понимают этот термин как защиту от любых нештатных ситуаций, включая потерю одного из узлов. Однако это неверно, да и сам термин отказоустойчивость не совсем удачен, поэтому вместо него в последнее время стараются использовать определение высокая доступность. Основной смысл отказоустойчивых конфигураций - это продолжение обслуживания клиентских запросов даже при недоступности одного из узлов, сами данные и настройки узла отказоустойчивая конфигурация никак не защищает.
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.
Заканчиваться файл зоны должен пустой строкой.