Linux для dns сервера

Содержание

Записки IT специалиста
Настраиваем отказоустойчивый DNS-сервер на базе BIND 9
Установка и настройка BIND 9 на первичном сервере
Настройка прямой зоны
Настройка обратной зоны
Проверка работы первичного DNS-сервера
Установка и настройка BIND 9 на вторичном сервере

Записки 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 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. Также обратите внимание, что доменные имена узлов следует указывать полностью, с точкой на конце.

Читайте также: Get all user name linux

Проверка работы первичного 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.8

nslookup 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 — адрес нашего первичного сервера с которого вторичный будет забирать изменения

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

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

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

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

Источник