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