DNS сервер bind9 на Ubuntu 18.04. Настройка Split DNS
В этой статье мы выполним настройку DNS сервера bind9 на Ubunu 18.04, на примере конфигурации Split DNS. Мы развернем bind9 в роли Master DNS. Разберемся как составлять зонные файлы и напишем локальную зону. Развернем вторичный DNS сервер. Напишем зону обратного просмотра для внутренней почты. Напишем зону для публичного просмотра и освоим на практике основные методы диагностики. Статья описывает тестовое развертывание доменной зоны, с полным описанием процесса, от установки bind9 до продакшена. Это не надергано из старых записей и все что здесь происходит, происходит на ваших глазах, сопровождается скриншотами и ни чем не отличается от боевого развертывания. С ошибками, которые встретятся на пути, будем так же бороться вместе. По мере продвижения я попытаюсь затронуть все важные нюансы. Так же я попытаюсь разбить материал на несколько кейсов, с которыми может столкнуться администратор доменной зоны.
Хочу сразу заметить, для того что б отвечать за зону в итернете, нам нужно два внешних статических ip-адреса, для двух наших ns-серверов, без этого хостер не делегирует зону.
DNS сервер. bind9
bind9. Установка ПО
Любая подобная работа начинается с обновления системы
sudo apt update && sudo apt upgrade -y
Устанавливаем bind9, так же нам понадобятся утилиты диагностики dig, nslookup, host, named-checkzone и named-checkconf Все это есть в этих двух пакетах
sudo apt install bind9 dnsutils -y
sudo service bind9 start
Вот конфигурационные файлы bind9
Основной конфигурационный файл нашего сервера /etc/bind/named.conf
cd /etc/bind && cat named.conf
Описывает общую конфигурацию сервера и для удобства может быть разбит на несколько других, что нам и предлагает дефолтный файл. Трогать мы его пока не будем
Он включает в себя еще три конфига
/etc/bind/named.conf.options
/etc/bind/named.conf.local
/etc/bind/named.conf.default-zones
-
bind9. named.conf.options
named.conf.options включает в себя общие параметры сервера, если посмотреть на него внимательно, он содержит в себе все что нам нужно. Я добавил несколько не обязательных директив: version "unknown" -этот параметр попросит валидотор, когда мы будем проверять зону. Еще я добавил директиву recursion no. Я противник рекурсивных запросов на нейм сервере, ответственном за зону. Каждый должен заниматься своим делом, пусть этим заниматься резольвер вышестоящего провайдера.
Открывай named.conf.options
sudo nano /etc/bind/named.conf.options
Предлагаю выпилить из него все лишнее и привести к более понятному виду
options {
version "unknown";
// dnssec-validation auto;
// auth-nxdomain no;
directory "/var/cache/bind";
recursion no;
listen-on {
172.16.0.0/16; # Какие сети слушаем
127.0.0.0/8; };
forwarders { 172.16.0.1; # Серверы имен вышестоящего провайдера, например, маршрутизатора
8.8.8.8; };
};
Давай посмотрим что получилось. Демон называется named, потому конфигурационные файлы и утилиты диагностики носят имя named
Для проверки синтаксиса конфигурационных файлов применяется утилита named-checkconf
sudo named-checkconf
named-checkconf -z служит для проверки синтаксиса зон
sudo named-checkconf -z
У нас их пока нет, но /etc/bind/named.conf.default-zones, который включен в общий конфиг, работают.
Наш bind9 работает, можно сказать "из коробки". Нужно всего лишь правильно написать зоны и настроить их представления. Подробное описание конфигурационных и зонных файлов содержится в первой половине нашей лабораторной работы. Если тебе не нужна локальная зона, я рекомендую хотя бы прочитать, это поможет лучше понять и не потерять последовательность в обилии материала. Ну а если не интересно, перематывай на Внешняя доменная зона, скриншоты всех конфигов там будут - разберешься
Локальная доменная зона. Первичный DNS сервер.
Первичный DNS сервер. Зона прямого просмотра.
Попробуем разобраться что такое зонные файлы и как они пишутся.
Создадим папку в которой будем хранить наши зонные файлы
sudo mkdir /etc/bind/master
Создадим файл, в котором будем описывать зону. У нас стоит задача построить split DNS, что б из локальной сети имена разрешались в локальные адреса, а с улицы во внешние. Потому будем использовать настоящее доменное имя. На самом деле, мой баян - мои правила и в своей локальной сети можно построить любой гугил из чужих адресов.
sudo touch /etc/bind/master/wmservice.pp.ua.local.zone
Файл мы создали, но что делать, если мы не знаем как его писать?
Для проверки зонных файлов служит утилита named-checkzone
Возьмем, да и скормим ему пустой файл. Указываем имя зоны и путь к файлу
sudo named-checkzone wmservice.pp.ua. /etc/bind/master/wmservice.pp.ua.local.zone
И узнаем, что у нас нет SOA-записи и NS-записи
-
Зона прямого просмотра. SOA-запись
SOA (англ. start of authority record) — ресурсная запись DNS о сервере, хранящем эталонную информацию о домене.
Как эти записи выглядят, мы можем у кого-то подсмотреть, воспользовавшись утилитой dig
Указываем тип записи -t SOA и зону, о которой нам нужна информация.
dig -t SOA google.com
Вот так будет выглядеть наша SOA-запись.
Отсюда ничего не копируй, я объясню из чего она состоит и приведу в более читаемый вид.
wmservice.pp.ua. 3600 IN SOA ns.wmservice.pp.ua. abuse.wmservice.pp.ua. 2021121001 10800 1200 604800 3600
1) wmservice.pp.ua. # Название зоны
2) 3600 # Время кеширования другими серверами
3) IN # Класс записи internet
4) SOA # Тип записи
5) ns.wmservice.pp.ua. # Сервер, ответственный за зону
6) abuse.wmservice.com.ua. # Почтовый адрес администратора (точка вместо собаки). Можно любой
7) 2021121001 # Серийный номер.
8) 10800 # Refresh - Интервал с которым вторичный опрашивает первичный
9) 1200 # Retry - Интервал между попытками, если первичный не доступен
10) 604800 # Expire - Время жизни зоны на других серверах, если первичный недоступен
11) 3600 # Minimum TTL - Тайм-аут
Можно использовать круглые скобки, которые обозначают начало и конец строчки.
Что б не писать ttl для каждой записи, мы используем переменную $ttl
Применение переменной $ORIGIN позволит не писать FQDN хостов в А-записях, а применять короткие имена.
Получилось так:
$ttl 3600
$ORIGIN wmservice.pp.ua.
wmservice.pp.ua. IN SOA (
ns.wmservice.pp.ua.
abuse.wmservice.pp.ua.
2021121001
10800
1200
604800
3600 )
SOA-запись есть
-
Зона прямого просмотра. NS-запись
Добудем NS- запись
Отлично. Еще нужно добавить А-записи для наших ns серверов.
-
Зона прямого просмотра. А-запись
Адресная запись, запись соответствия между именем и IP-адресом
Представлена она в таком формате
Теперь, когда у нас есть все записи и ты знаешь как писать зонный файл, предлагаю его написать
sudo nano /etc/bind/master/wmservice.pp.ua.local.zone
Что б сэкономить время в дальнейшем, сразу добавим WEB-сервер 172.16.101.3. Собака обозначает текущий домен, т.е. наш веб сервер будет иметь доменное имя wmservice.pp.ua.
Получается такой файл, копируй, сохраняй
$ttl 3600
$ORIGIN wmservice.pp.ua.
wmservice.pp.ua. IN SOA (
ns.wmservice.pp.ua.
abuse.wmservice.pp.ua.
2021121001
10800
1200
604800
3600 )
@ IN NS ns.wmservice.pp.ua.
@ IN NS ns2.wmservice.pp.ua.
@ IN A 172.16.101.3
ns IN A 172.16.0.5
ns2 IN A 172.16.0.6
Проверим
sudo named-checkzone wmservice.pp.ua. /etc/bind/master/wmservice.pp.ua.local.zone
Удивительно😃
-
bind9. named.conf.local
Хорошо, зона составлена, и мы можем внести ее в конфигурацию нашего нейм сервера. В named.conf, был включен еще один файл named.conf.local
Покопавшись в котором, становится понятно в каком формате нужно прописывать зону.
Если бы мы пошли этим путем сразу и посмотрели что в файле /etc/bind/db.empty, мы бы увидели формат зонного файла. Но я хотел показать, как можно легко, анализируя файлы и применяя утилиты диагностики, ориентироваться в системе.
Открываем named.conf.local
В этот файл мы будем добавлять все свои локальные зоны
sudo nano /etc/bind/named.conf.local
Мне такой формат больше нравится
Название зоны
Тип сервера
Абсолютный путь к зонному файлу
zone "wmservice.pp.ua." {
type master;
file "/etc/bind/master/wmservice.pp.ua.local.zone";
};
Воспользуемся знакомой утилитой, убедимся что все в порядке и перезагрузим bind9
sudo named-checkconf
sudo named-checkconf -z
sudo service bind9 restart
sudo service bind9 status
*no valid RRSIG resolving - Я у себя забыл эти директивы закомментировать. dnssec валидация в локальной сети терубет отдельной настройки, мы не будем ее касаться
bind9. Настройка представлений
-
named.conf
acl
view
allow-query
match-clients
Настройка представлений в bind9 позволяет разрешать имена на основе адресов клиентов. Необходимая часть настройки Split DNS, где клиентам из разных подсетей нужно раздать разные зоны.
sudo nano /etc/bind/named.conf
include "/etc/bind/named.conf.options";
acl "local" { 172.16.0.0/16; };
view "local" {
include "/etc/bind/named.conf.local";
match-clients { local; };
};
include "/etc/bind/named.conf.default-zones";
sudo named-checkconf
Ругается, говорит - что, если начали писать view представления, то нужно писать для всех зон.
Выпиливаем, нам это не нужно
Другое дело
sudo service bind9 restart
sudo service bind9 status
Красота
Первичный DNS сервер. Проверим
С другого компьютера локальной сети, спросить наличие SOA-записи у сервера 172.16.0.5
dig @172.16.0.5 -t SOA wmservice.pp.ua
Наш сервер имен работает и отдает нашу SOA запись
И все то у нас работает
Еще, вопросы доступа можно решать с помощью директивы allow-query как на уровне параметров сервера, так и каждой зоны. Как ты уже понял, всё равно всё подтягивается в named.conf
Можно, как разрешить запросы всем allow-query { any; };, так и прописать только те узлы, которым разрешено. В директивах match-clients и acl так же можно прописывать, как сети, так и узлы. Иногда это делается целыми списками, в таком случае, можно завести еще один include
(Не вноси, это просто примеры)
bind9. Правила логирования.
Гибкая настройка логирования в bind9 позволяет устанавливать глубину и перенаправлять логи в разные файлы, в зависимости от категории. Приведу несколько примеров. Можно создать все эти файлы правил, закомментировать и подключать в основной конфиг, в зависимости от ситуации. Для анализа неисправностей лучше всего подходит дебаг в один файл
tail -f /var/lib/bind/bind-debug.log
Опрашиваешь сервер и в реальном времени смотришь с каких адресов прилетают запросы и что происходит на сервере
Добавляем в named.conf
Но пока закомментируем, это позволить видеть ошибки в systemctl
//include "/etc/bind/logrules.notice";
//include "etc/bind/logrules.debug-singl";
//include "/etc/bind/logrules.debug-diff";
//include "/etc/bind/logrules.debug-full";
Правила логирования bind9. Notice в один файл
sudo nano /etc/bind/logrules.notice
logging {
channel bind-notice.log {
file "/var/lib/bind/bind-notice.log" versions 10 size 20m;
severity notice;
print-category yes;
print-severity yes;
print-time yes;
};
category queries { bind-notice.log; };
category default { bind-notice.log; };
category config { bind-notice.log; };
};
Только файл /var/lib/bind/bind-debug.log в который мы планируем писать логи, создавать не нужно, bind его создаст от своего пользователя.
Ну либо выдавать ему 666 права, а то получим ошибку доступа.
Путь /var/lib/bind/ выбран потому, что bind9 разрешено по умолчанию писать в этот каталог. Если хочешь другой путь, его нужно прописать в apparmor (листай ниже Настройка Apparmor)
Правила логирования bind9. debig в один файл
sudo nano /etc/bind/logrules.debug-singl
logging {
channel bind.log {
file "/var/lib/bind/bind-debug.log" versions 10 size 20m;
severity debug;
print-category yes;
print-severity yes;
print-time yes;
};
category queries { bind.log; };
category default { bind.log; };
category config { bind.log; };
};
Правила логирования bind9. debug в разные файлы
sudo nano /etc/bind/logrules.debug-full
logging {
channel "misc" {
file "/var/lib/bind/misc.debug.log" versions 4 size 4m;
severity debug;
print-time YES;
print-severity YES;
print-category YES;
};
channel "query" {
file "/var/lib/bind/query.debug.log" versions 10 size 4m;
severity debug;
print-time YES;
print-severity YES;
print-category YES;
};
channel "config" {
file "/var/lib/bind/config.debug.log" versions 10 size 4m;
severity debug;
print-time YES;
print-severity YES;
print-category YES;
};
channel "security" {
file "/var/lib/bind/security.debug.log" versions 10 size 4m;
severity debug;
print-time YES;
print-severity YES;
print-category YES;
};
channel "client" {
file "/var/lib/bind/client.debug.log" versions 10 size 4m;
severity debug;
print-time YES;
print-severity YES;
print-category YES;
};
channel "database" {
file "/var/lib/bind/database.debug.log" versions 10 size 4m;
severity debug;
print-time YES;
print-severity YES;
print-category YES;
};
channel "lame" {
file "/var/lib/bind/lame.debug.log" versions 10 size 4m;
severity debug;
print-time YES;
print-severity YES;
print-category YES;
};
category default { "misc"; };
category queries { "query"; };
category config { "config"; };
category security { "security"; };
category database { "database"; };
category client { "client"; };
category "lame-servers" { "lame"; };
};
Перечитываем конфигурацию и перезагружаем bind9
Если вторичный разворачивать не будешь, запрети трансфер в целях безопасности
Базовая настройка первичного DNS сервера закончена
Мы развернули DNS сервер на bind9, написали зону и внесли в конфигурацию основные параметры для работы сервера. Но впереди у нас еще куча работы. Будем подключать вторичный сервер, добавим МХ-запись для почтового сервера и напишем зону обратного просмотра. Работа будет проходить именно в таком порядке, так как хочется соблюсти логическую последовательность действий, при разворачивании зоны "с ноля". Если вторичный DNS сервер тебе не нужен, настрой рабочую станцию и просто перемотай на Добавление ресурсных записей
Настройка рабочей станции
резольвер
Мы развернули сервер имен с локальной зоной, но если спросить нашу рабочую станцию, то мы увидим что то типа
Так происходит потому, что системный резольвер нашей станции не знает о сервере. В масштабах предприятия настраивается отдельный, кеширующий резольвер, к которому подключают рабочие станции. Но сейчас мы этим заниматься не будем, а просто настроим резольвер на клиенте
Откроем файл
sudo nano /etc/systemd/resolved.conf
Добавим
[Resolve]
DNS=172.16.0.5
Domains=wmservice.pp.ua # можно еще так сделать, в этом домене будет искать первым делом
Перезагружаем демон
sudo service systemd-resolved restart
Проверяем
nslookup wmservice.pp.ua
host ns.wmservice.pp.ua
Имена разрешаются правильно
И даже сайт доступен
Локальная доменная зона. Вторичный DNS сервер.
Переходим к настройке вторичного нейм сервера, под который мы уже определили место в нашей SOA записи. Хост ns2.wmservice.pp.ua.
Вторичный DNS сервер.Установка bind9
Обновляем систему
sudo apt update && sudo apt upgrade -y
Установим bind9 и dnsutils
sudo apt install bind9 dnsutils -y
sudo service bind9 start
cd /etc/bind
Вторичный DNS сервер. Настройка bind9
Создаем папку для хранения дампов зонных файлов
sudo mkdir slave
Даем ей права
sudo chmod g+w slave/
Задаем параметры сервера
sudo nano named.conf.options
options {
version "unknown";
// dnssec-validation auto;
// auth-nxdomain no; # conform to RFC1035
recursion no;
directory "/var/cache/bind";
listen-on {
172.16.0.0/16;
127.0.0.0/8;
};
forwarders { 172.16.0.1; };
};
Вторичный DNS сервер. Настройка зоны
Указывает название зоны
Тип сервера
Абсолютный путь к зонному файлу
IP-адрес первичного DNS сервера
sudo nano /etc/bind/named.conf.local
zone "wmservice.pp.ua." {
type slave;
file "/etc/bind/slave/wmservice.pp.ua.local.zone";
masters { 172.16.0.5; };
};
Настраиваем представления в named.conf
sudo nano /etc/bind/named.conf
include "/etc/bind/named.conf.options";
acl "local" { 172.16.0.0/16; };
view "local" {
match-clients { local; };
include "/etc/bind/named.conf.local";
};
//include "/etc/bind/logrules.debug-singl";
Вторичный DNS сервер. Логирование
sudo nano /etc/bind/logrules.debug-singl
logging {
channel bind.log {
file "/var/lib/bind/bind-debug.log" versions 10 size 20m;
severity debug;
print-category yes;
print-severity yes;
print-time yes;
};
category queries { bind.log; };
category default { bind.log; };
category config { bind.log; };
};
*Листай выше, там есть больше (Правила логирования)
Вторичный DNS сервер. Проверка
Проверим синтаксис, не наделали ли мы ошибок
sudo named-checkconf
sudo named-checkconf -z
Проглотил, что ж, попробуем перезагрузить bind9
sudo service bind9 restart
Команда rndc retransfer выполнит трансфер зоны без проверки серийного номера. Запомни ее. Она пригодится, если накосячил с серийником (чуть дальше объясню). А в данном случае позволит не ждать тайм-аут и выполнить обновление зоны вручную
sudo rndc retransfer wmservice.pp.ua.
sudo service bind9 status
Ну вот, а так все хорошо начиналось
Что же нам говорит журнал
journalctl -ex
А журнал нам говорит, что все у нас замечательно) - трансферс прошел успешно, но apparmor не разрешил записать дамп в папку /etc/bind/slave
apparmor="DENIED"
Если на первичном сервере мы сами писали зонные файлы, то вторичный их получает с мастера и записывает в том формате, в котором ему удобно, эта информация служебная, она не предназначена для пользователя. Но bind9 должен иметь права писать в системную папку, для этого нужно настроить Apparmor
*network unreachable resolving - в опциях не выключена dnssec-validation
Вторичный DNS сервер. Настройка Apparmor
Apparmor - Программный интструмент упреждающей защиты системных ресурсов
sudo nano /etc/apparmor.d/usr.sbin.named
Добавляем строчку, туда где про bind
/etc/bind/slave/** rwm,
Так же сюда можно вносить директории для логов
sudo systemctl restart apparmor.service
sudo service bind9 restart
sudo service bind9 status
*network unreachable resolving - в опциях не выключена dnssec-validation
Пробуем еще раз
sudo rndc retransfer wmservice.pp.ua.
journalctl -ex
Замечательно, трансфер выполнен успешно
Запросим с рабочей станции SOA запись у вторичного нейм сервера
dig @172.16.0.6 -t SOA wmservice.pp.ua
Вторичный DNS сервер мы настроили
Локальная доменная зона. Возвращаемся на мастер
Открываем /etc/bind/named.conf
И ограничиваем трансфер, ip-адресом нашего второго DNS сервера
Перечитываем конфигурацию на наличие ошибок и перезагружаем bind9
Настройка локальной зоны вторичного DNS сервера закончена
DNS сервер. Добавление ресурсных записей
- MX-запись
- А-запись
Следующий кейс, который мы рассмотрим, это редактирование рабочей зоны, на примере добавления MX-записи
Запись MX (от англ. mail exchanger) — тип DNS-записи, предназначенный для маршрутизации электронной почты с использованием протокола SMTP.
Запись А Адресная запись, соответствие между именем и IP-адресом
В нашей системе есть почтовый сервер с именем хоста mail. Обычно используют имя mx, но это ровным счетом не имеет ни какого значения, пусть будет mail. FQDN mail.wmservice.pp.ua. Для него нам нужно добавить адресную запись-А и МХ-запись,.
Добавление ресурсных записей. Первичный DNS сервер
Все операции по редактированию зон производятся на первичном нейм сервере, на вторичном хранятся только дампы.
Открываем файл описания зоны
sudo nano /etc/bind/master/wmservice.pp.ua.local.zone
Вторичный нейм сервер не читает содержание зоны, он смотрит на серийный номер, если тот увеличился, выполняет трансфер. Важно повышать серийник каждый раз при редактировании зоны. Если номер понизить, вторичные серверы прекратят трансфер такой зоны и начнутся проблемы. Исправить ситуацию можно двумя способами. Если доступна консоль вторичных серверов, выполнить команду rndc retransfer Зона обновится, игнорируя серийный номер. Во втором случае, если доступна только консоль мастера, можно повышать номер (точно не помню допустимый интервал), пока не достигнем заданного числа или не прогоним серийный номер на второй круг.
Добавляем нужные ресурсные записи и не забываем подкрутить серийный номер.
IN MX 10 mail.wmservice.pp.ua.
mail IN A 172.16.101.2
10 - это приоритет почтового сервера, чем ниже число - тем выше приоритет
Проверяем зону
sudo named-checkzone wmservice.pp.ua. /etc/bind/master/wmservice.pp.ua.local.zone
Если все хорошо, перезапустим bind9
sudo service bind9 reload
Проверим, запросив у нашего DNS сервера МХ-запись. Мы не настраивали рекурсию и не настраивали резольвер на этом сервере, вышестоящий DNS провайдера тоже не знает о нашей зоне, потому запрос к 127.0.0.1 не приведет к ожидаемому результату. Делаем запрос к 172.16.0.5
dig @172.16.0.5 -t MX wmservice.pp.ua.
Наша запись добавилась
Можешь подождать пока обновиться вторичный, либо выполнить трасфер вручную
Добавление ресурсных записей. Вторичный DNS сервер
Запросим трансфер
sudo rndc retransfer wmservice.pp.ua.
Но мы настраивали резольвер на рабочей станции и диагностику лучше проводить оттуда.
Запрашивая или добавляя МХ-запись, нужно понимать, что делаем мы это для домена wmservice.pp.ua., а не для mail.wmservice.pp.ua - mail это всего лишь почтовый хост!!!
Запись запрашиваем для домена wmservice.pp.ua.
Самая нижняя строчка нам дословно говорит:
"Почту wmservice.pp.ua обслуживает 10 mail.wmservice.pp.ua"
Точно так же вносятся ТХТ-записи, так же для домена, а не для почтового хоста!
Настройка ТХТ-записей выходит за рамки данной статьи и должна быть рассмотрена в настройке почтового сервера.
DNS сервер. Зона обратного просмотра.
Зона обратного просмотра. PTR запись
На примере добавления зоны обратного просмотра, мы рассмотрим добавление в обслуживание нашим DNS сервером еще одной зоны.
Обратный просмотр DNS (англ. reverse DNS lookup) — обращение к особой доменной зоне для определения имени узла по его IP-адресу c помощью PTR-записи.
- IPv4-адрес 192.168.0.1 превращается в 1.0.168.192.in-addr.arpa.;
- IPv6-адрес 2001:db8::567:89ab — в b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.[1].
Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.
Это именно та запись, которую многие провайдеры не хотят вносить, потому что не владеют адресным пространством, а у кого то его арендуют. Это такая же запись, как и А-запись, только наоборот. Если А-запись содержит информацию о доменном имени - на каких IP-адресах оно квартируется, то PTR-запись говорит про IP-адрес, какое доменное имя имеет хост, расположенный на данном адресе. Говоря простым языком: А-запись - доменное имя в IP-адрес; PTR - IP-адрес в доменное имя. Используется она в основном для проверки валидности почтовых серверов. Имеет вид инверсии IP-адреса в домене in-addr.arpa. Конкретно в нашей лабораторной работе имеет смысл рассмотреть эту зону только в контексте локального DNS, так как в своей локальной сети все адресное пространство принадлежит нам. В отличии от адресов в интернете, где такую запись выдает администратор автономной системы сети, в которую входит наш интернет-адрес. Но мы обязательно вернемся к этому вопросу, когда будем администрировать подсеть в интернете😉
А пока я покажу как это делается на примере нашей локальной зоны. Посмотрим что из себя представляет PTR-запись для IP-адреса 8.8.8.8
Воспользуемся знакомой утилитой dig
Даже без всяких com - им можно😃
И как я говорил, сохраняется иерархия доменных имен - мы видим точно такую же зону и точно такие же ресурсные записи.
Получается, что нам просто нужно создать новую зону 16.172.in-addr.arpa.zone
Зона обратного просмотра. Создаем новый зонный файл
sudo nano /etc/bind/master/16.172.in-addr.arpa.zone
Наш сервер имен настроен, работает и имеет А-запись, для описание новой зоны понадобится только SOA и NS записи, смотри
Вставляй
$TTL 3600
$ORIGIN 16.172.in-addr.arpa.
16.172.in-addr.arpa. IN SOA (
ns.wmservice.pp.ua.
admin.wmservice.com.ua.
2021121000
10800
1200
604800
3600 )
IN NS ns.wmservice.pp.ua.
IN NS ns2.wmservice.pp.ua.
3.101.16.172.in-addr.arpa. IN PTR wmservice.pp.ua.
5.0.16.172.in-addr.arpa. IN PTR ns.wmservice.pp.ua.
6.0.16.172.in-addr.arpa. IN PTR ns2.wmservice.pp.ua.
2.101.16.172.in-addr.arpa. IN PTR mail.wmservice.pp.ua.
Хотя я и применил переменную $ORIGIN, я все равно написал имена полностью, что б было понятно, что доменным именем является 16.172.in-addr.arpa., а ip-адресом wmservice.pp.ua.
Смотрим что получилось
sudo named-checkzone 16.172.in-addr.arpa /etc/bind/master/16.172.in-addr.arpa.zone
Как то так
Внесем в конфиг bind9
Как я уже говорил, наши локальные зоны мы прописываем в named.conf.local
sudo nano /etc/bind/named.conf.local
Добавляем
zone "16.172.in-addr.arpa." {
type master;
file "/etc/bind/master/16.172.in-addr.arpa.zone";
allow-transfer { 172.16.0.6; };
};
В нашем варианте, когда 2 сервера в одной сети, allow-transfer можно прописать один для всех в named.conf.options .Но разные конфигурации бывают и такой вариант позволяет строить различные конфигурации из серверов имен.
Сохраняем, проверяем синтаксис, перезагружаем bind9
Зона обратного просмотра. Вторичный DNS сервер
И так же добавляем зону в named.conf.local нашего bind9
zone "16.172.in-addr.arpa." {
type slave;
file "/etc/bind/slave/16.172.in-addr.arpa.zone";
masters { 172.16.0.5; };
};
Проверяем с рабочей станции
Огонь
Точно таким же образом добавляются и другие доменные зоны
Ну ты понял😃
На этой радостной ноте, развертывание локальной доменной зоны, можно считать завершенным.
Таким образом мы построили свой маленький, частный intranet и можно начинать торговать доменными именами😃😃
А мы продолжаем развертывание.
Внешняя доменная зона.
Для правильной работы Split DNS, на маршрутизаторе необходимо настроить проброс 53 портов в режиме SNAT 1:1 . Так как в конфигурации Virtual Server, запросы с интернета будут приходить с порта маршрутизатора и такой трафик будет оцениваться, как трафик локальной сети.
Внешняя доменная зона. Первичный DNS сервер
named.conf.options привести к следующему виду
Добавляем внешний адрес в директиву listen-on
Создаем зонный файл
cd /etc/bind/ && sudo nano /etc/bind/master/wmservice.pp.ua.zone
Это точно такой же файл, как мы писали для локальной зоны. Поменялись только IP-адреса на внешние и серийный номер
$ttl 3600
$ORIGIN wmservice.pp.ua.
wmservice.pp.ua. IN SOA (
ns.wmservice.pp.ua.
abuse.wmservice.com.ua.
2021121100
10800
1200
604800
3600 )
@ IN NS ns.wmservice.pp.ua.
@ IN NS ns2.wmservice.pp.ua.
@ IN A 95.47.116.212
ns IN A 95.47.116.212
ns2 IN A 46.172.75.114
Проверяем
sudo named-checkzone wmservice.pp.ua. /etc/bind/master/wmservice.pp.ua.zone
Возвращаясь к настройке NAT и внутренней маршрутизации, хочу отметить. Прописывая allow-transfer, учитывайте откуда прилетают запросы, когда один нейм сервер стучится к другому через внешний адрес. Если это все находится на одном маршрутизаторе, то дальше него запрос не уйдет и вернется назад с адреса маршрутизатора.
Наша лаба в одной подсети и весь трансфер мы завернем на локальный адрес.
Зоны для внутреннего просмотра мы подключали через named.conf.local.
Для зон внешнего просмотра создадим другой файл, чуть позже объясню почему
sudo nano /etc/bind/named.conf.external
zone "wmservice.pp.ua." {
type master;
file "/etc/bind/master/wmservice.pp.ua.zone";
allow-transfer { 172.16.0.6; };
};
Пропишем его в named.conf
sudo nano /etc/bind/named.conf
Добавляем такой блок
acl "external-view" { 95.47.116.212; };
view "external-view" {
recursion no;
match-clients { external-view; };
include "/etc/bind/named.conf.external";
};
Оперируя директивами acl view и match-clients, мы можем раздавать разные доменные зоны, клиентам из разных подсетей. Для этого мы и подключали зоны через разные инклюды (external и local). Обрати внимание, рекурсию мы запретили на уровне общей конфигурации сервера, но можно это делать для каждой группы зон. Такой метод применяется, если есть зоны, где нужно разрешить рекурсивные запросы. Так же можно написать везде и это не будет считаться ошибкой, главное, что б не противоречило.
Проверяем нашу зону
sudo named-checkconf -z
sudo named-checkzone wmservice.pp.ua. /etc/bind/master/wmservice.pp.ua.zone
Перезагружаем bind9
sudo service bind9 restart
sudo service bind9 status
Готово
Внешняя доменная зона. Вторичный DNS сервер
Конфигурацию сервера приводим к такому виду
sudo nano /etc/bind/named.conf.options
Указываем интернет-адрес
options {
version "unknown";
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
recursion no;
directory "/var/cache/bind";
listen-on {
46.172.75.114/24;
172.16.0.0/16;
127.0.0.0/8;
};
};
Так же создаем новый файл named.conf.external
sudo nano /etc/bind/named.conf.external
zone "wmservice.pp.ua." {
type slave;
file "/etc/bind/slave/wmservice.pp.ua.zone";
masters { 172.16.0.5; };
};
Прописываем в named.conf
sudo nano /etc/bind/named.conf
Добавить блок
acl "external-view" { 46.172.75.114; };
view "external-view" {
recursion no;
match-clients { external-view; };
include "/etc/bind/named.conf.external";
};
Попробуй выполнить трансфер
sudo rndc retransfer wmservice.pp.ua.
Ага?😃
У нас две зоны с одинаковым названием и наш сервер не понимает что мы от него хотим. Тут нужно указать то, что прописано в view.
Внешняя доменная зона. Проверка
Если с рабочей станции спросить наш сервер, он разрешит имена в адреса локальной сети
На запрос с интернета в ответ мы получим вторую зону
(C телефона)
Проверим второй сервер
(Локалка)
Интернет
У нас все получилось и домен работает как задумано
Если это не так, нужно проверить конфигурацию NAT на маршрутизаторе, должна быть 1:1 SNAT. Вторая причина может быть в директивах acl view match-clients по разным файлам. Это обратная сторона разделения конфига.
Включай tail -f /var/lib/bind/bind-debug.log и смотри с каких адресов прилетают запросы и что происходит на сервере
Наши DNS серверы настроены и можно проверить зону онлайн-валидатором
Я пользуюсь сервисом https://www.dnsinspect.com
Не удивительно, так как мы еще ничего не делали на стороне хостинг-провайдера, который обслуживает наш домен и видим информацию о его серверах. Идем на его сайт в админ панель, и находим в настройках домена NS-серверы.
Вносим свои
Обновление может занимать долгое время, провайдер анонсирует от 2 до 48 часов. Можно отвлечься на часик-другой.
Я проверил минут через 40
Вот таких результатов я стараюсь добиваться в своей работе, чего и Вам желаю
Для тех, кто продержался с нами до конца и всё осилил, бонус - утилита lsd 😃
wget https://github.com/Peltoche/lsd/releases/download/0.20.1/lsd_0.20.1_amd64.deb
sudo dpkg -i lsd_0.20.1_amd64.deb
Пропиши свои команды
nano ~/.bashrc
alias lla='lsd -l'
alias lll='lsd -la'
alias llt='lsd --tree'
Не грусти ))
Больше интерсеных и полезных статей, ты найдешь в блоге нашей акедемии.
https://blog.yodo.im
2021 ©brat