Записки IT специалиста
Настраиваем отказоустойчивый DNS-сервер на базе BIND 9
DNS-сервер относится к наиболее критичным элементам сетевой инфраструктуры, так как именно на него возлагается задача разрешения доменных имен, без которой трудно представить работу любой сети. Поэтому важно не допускать перебоев в обслуживании клиентов, а справиться с этой задачей нам поможет отказоустойчивая конфигурация из нескольких DNS-серверов. В данной статье мы рассмотрим, как создать собственную инфраструктуру DNS при помощи полнофункционального и открытого DNS-сервера BIND 9.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Прежде всего коснемся понятия отказоустойчивости, многие неправильно понимают этот термин как защиту от любых нештатных ситуаций, включая потерю одного из узлов. Однако это неверно, да и сам термин отказоустойчивость не совсем удачен, поэтому вместо него в последнее время стараются использовать определение высокая доступность. Основной смысл отказоустойчивых конфигураций — это продолжение обслуживания клиентских запросов даже при недоступности одного из узлов, сами данные и настройки узла отказоустойчивая конфигурация никак не защищает.
BIND 9 — это полнофункциональный открытый DNS-сервер, имеющий широкое распространение, 10 из 13 корневых DNS-серверов работают именно на BIND. В данной статье мы будем рассматривать установку BIND в среде Debian или Ubuntu, все действия, если не указано иного, выполняются с правами суперпользователя (root). Также предполагается, что читатель имеет представление о назначении DNS-сервера и основных типах DNS-записей.
Установка и настройка BIND 9 на первичном сервере
Установка BIND и всех необходимых пакетов производится одной командой:
При этом обратите внимание, что несмотря на то, что имя пакета bind9 установленная служба имеет название named.
Затем откроем файл /etc/bind/named.conf.options и после строки:
Добавим следующие настройки:
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 TTLTTL — время жизни 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-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.8nslookup 192.168.72.7 192.168.72.8Чтобы запрос был направлен именно нашему серверу мы явно указываем его адрес вторым параметром команды.
В обоих случаях вы должны получить правильные ответы, после чего можно переходить к настройке вторичного DNS-сервера.
Установка и настройка BIND 9 на вторичном сервере
Точно также установим пакет на второй сервер:
И сразу перейдем к /etc/bind/named.conf.options, настройки которого полностью аналогичны первичному серверу, за исключением строки:
В которой следует указать 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 — адрес нашего первичного сервера с которого вторичный будет забирать изменения
После чего проверяем правильность конфигурации:
На этом настройка вторичного сервера закончена, можем проверить его работу аналогично тому, как мы это делали для первичного сервера.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: