Установка DNS сервера Bind9 на UbuntuServer 24.04 с WebMin в Proxmox

Развёртывание DNS-сервера BIND9 для OT-сети Самара

Статус документа: рабочая пошаговая инструкция, основанная на фактически выполненной и проверенной установке.

Редакция: 17, состояние проекта на 05.11.2026.

Редакция 17 является развитием редакции 16. Все ранее проверенные разделы, команды, конфигурационные файлы, пилоты, правила UFW, Netplan, BIND9, Webmin, Windows DDNS, контроль PTR/A и production management сохранены. Дополнительно зафиксирована интеграция с многосетевыми Linux-серверами: split DNS через systemd-resolved, сегментные FQDN, RFC 2136 через nsupdate и автоматическая регистрация через systemd.

Текущее состояние: BIND9 работает как выделенный авторитетный DNS для одной прямой и восьми обратных OT-зон; рекурсия и forwarder отключены. DDNS включён во всех девяти рабочих зонах и ограничен проектными сетями через allow-update. Регистрация A/PTR подтверждена во всех пяти OT-сетях, включая вторые половины сетей /23; reverse-зоны используют однозначные локальные SOA MNAME/NS-имена.

Production management-интерфейс ens23 имеет адрес 10.44.100.228/24. Доступ по SSH и Webmin с маршрутизируемой административной сети 10.44.0.0/21 подтверждён с узла 10.44.3.65 после добавления точных UFW-разрешений. Целевой режим после завершения переноса — без доступа DNS-ВМ в Интернет, без системных DNS-серверов Ubuntu и без default route; для управления и внутреннего NTP используются только явно заданные статические маршруты через 10.44.100.1.

1. Концепция проекта: что строим и как это работает

1.1. Задача проекта

В OT-сетях много устройств со статическими IP-адресами. Запоминать и сопровождать только адреса неудобно, поэтому создаётся собственная DNS-зона ot-samara.baltika.ru и набор обратных зон. В результате инженер может обращаться к оборудованию по понятному имени, а по IP-адресу можно определить зарегистрированное имя.

Имя оборудования → A-запись → IP-адрес

IP-адрес          → PTR-запись → имя оборудования

Один экземпляр BIND9 обслуживает несколько OT-подсетей. У виртуальной машины есть отдельный локальный DNS-адрес в каждой сети, поэтому клиент обращается к адресу своего сегмента и не зависит от межвлановой маршрутизации.

1.2. Инструменты, лицензии и назначение

Компонент	Для чего используется	Стоимость и лицензирование
Proxmox VE	Запускает отдельную виртуальную машину DNS и подключает её виртуальные сетевые карты к нужным bridge/VLAN.	Свободное ПО AGPLv3; использовать можно без платы. Платная подписка нужна только для enterprise-репозитория и коммерческой поддержки. Официальное описание.
Ubuntu Server 24.04 LTS	Гостевая операционная система, в которой работают BIND9, UFW, Webmin и диагностические утилиты.	Свободно скачивается и используется; стандартная поддержка LTS предоставляется бесплатно, Ubuntu Pro является дополнительной услугой. Официальная страница.
BIND9	Авторитетный DNS-сервер: хранит зоны и отвечает на запросы A, CNAME, PTR, NS и SOA; принимает DDNS от разрешённых статических Windows-клиентов.	Свободное ПО под MPL 2.0, отдельная лицензия не требуется. Официальная страница ISC.
Webmin	Веб-интерфейс для редкого ручного добавления и изменения DNS-записей, просмотра служб и базового администрирования.	Свободное ПО под BSD-3-Clause, отдельная лицензия не требуется. Официальное описание.
UFW	Host firewall: разрешает DNS только из нужных OT-сетей, а SSH и Webmin — только из management-сетей.	Входит в репозиторий Ubuntu; отдельной платы нет.
systemd, rndc, dig, named-checkconf, named-checkzone, tcpdump	Управление службами, безопасное перечитывание BIND, проверка синтаксиса, DNS-тесты и анализ трафика.	Штатные свободные компоненты Ubuntu/BIND, отдельной платы нет.
QEMU Guest Agent	Передаёт Proxmox сведения о гостевой системе и обеспечивает корректное взаимодействие с ВМ.	Свободный пакет из Ubuntu, отдельной платы нет.
BookStack	Хранит эту инструкцию, схему адресации, правила эксплуатации и историю решений. В DNS-службу не входит.	Свободное ПО под MIT License. Официальное описание.
Windows-клиенты	Проверяют прямое и обратное разрешение; компьютеры со статическими IP выполняют DDNS.	Используются уже имеющиеся лицензированные ОС; в стоимость серверного решения не входят.

Итог по стоимости: весь серверный программный стек можно развернуть без лицензионных платежей. Платными остаются только необязательная коммерческая поддержка/подписки и существующие лицензии Windows.

1.3. Как проходит обычный DNS-запрос

OT-клиент

  ↓ UDP/53 или TCP/53 на локальный DNS-адрес своей подсети

UFW

  ↓ проверяет входной интерфейс, сеть источника, адрес назначения и порт

BIND9

  ↓ читает авторитетную прямую или обратную зону

Ответ клиенту: IP по имени или имя по IP

Для имён из ot-samara.baltika.ru сервер отвечает авторитетно. Для внешних доменов он возвращает REFUSED, потому что рекурсия и пересылка запросов намеренно отключены.

1.4. Как выполняется администрирование

Компьютер администратора

  ↓ HTTPS/TCP 10000 через management-сеть

Webmin

  ↓ для динамической зоны выполняет Freeze → Edit → Thaw

BIND9

  ↓ сохраняет live-изменения DDNS в журнале .jnl

Пользовательская команда «Синхронизировать DDNS-зоны»

  ↓ выполняет rndc sync для всех рабочих зон

Файлы зон и Webmin

  ↓ показывают актуальное синхронизированное состояние

Webmin не заменяет BIND9 и не хранит отдельную базу DNS-записей. Работающий named обслуживает динамические зоны из основного файла вместе с журналом .jnl. Поэтому просмотр файла зоны или страницы Webmin без предварительного rndc sync может не показать только что полученную DDNS-запись, хотя запрос dig уже возвращает её.

После ручного изменения динамической зоны проверяются named-checkzone, named-checkconf -z, состояние rndc zonestatus и контрольные запросы dig. Целевое состояние каждой рабочей зоны: dynamic: yes, frozen: no.

1.5. Текущий и планируемый режим наполнения зон

Тип узла	Как появляются записи
Статические Windows-компьютеры	DNS Client регистрирует A и PTR через RFC 2136. На OT-интерфейсе задаются статический адрес, локальный DNS своей сети и суффикс ot-samara.baltika.ru.
ПЛК, HMI, счётчики и устройства без DDNS	Пары A/PTR добавляются вручную через Webmin по процедуре безопасного редактирования динамической зоны.
Старые PTR после переноса Windows-хоста	Проверяются и удаляются отдельной утилитой /usr/local/sbin/bind-ptr-mismatch; Windows не гарантирует удаление PTR из прежней reverse-зоны.

Для многосетевых Linux-серверов: обычные одноинтерфейсные узлы продолжают регистрироваться как HOST.ot-samara.baltika.ru. Для редких серверов с несколькими OT-интерфейсами применяется отдельное сегментное FQDN на каждый интерфейс: HOST.legacy.ot-samara.baltika.ru, HOST.pivo.ot-samara.baltika.ru, HOST.rozliv.ot-samara.baltika.ru, HOST.utilities.ot-samara.baltika.ru и HOST.astue.ot-samara.baltika.ru. Регистрация таких A/PTR выполняется контролируемым скриптом nsupdate на самом Linux-сервере.

DDNS разрешён только из проектных OT-сетей. Это сетевое ограничение, а не криптографическая аутентификация: узел с разрешённым адресом потенциально может отправлять UPDATE. Для усиления защиты позднее следует рассмотреть TSIG, GSS-TSIG либо централизованное обновление через доверенный DHCP.

Сервер не выполняет функции DHCP, маршрутизатора или публичного recursive DNS. Он является специализированным авторитетным DNS-сервисом для OT.

1.6. Как устроены исполняемые примеры в этой инструкции

Команды создания конфигураций приведены в исполняемом виде: с точными путями, именами интерфейсов, IP-адресами, зонами и комментариями для каждой сети. Для записи файлов используется команда tee с heredoc: содержимое между строками EOF записывается в указанный файл без подстановки переменных оболочки.

Важно: блоки «ожидаемый результат» не вводятся в терминал. Конфигурация Proxmox-хоста не заменяется готовым /etc/network/interfaces, потому что этот файл содержит посторонние для DNS-сервера bridge, адреса и физические интерфейсы конкретного узла. Для Proxmox приведена точная карта уже используемых bridge, VLAN-подинтерфейсов, VM netX и MAC-адресов.

2. Принятая архитектура

DNS-сервер разворачивается на отдельной виртуальной машине в Proxmox VE. BIND9 устанавливается нативно из репозитория Ubuntu, без Docker.

Параметр	Значение
Имя виртуальной машины	SMR-SRV-OT-DNS
Hostname Ubuntu	smr-srv-ot-dns
Операционная система	Ubuntu Server 24.04.4 LTS
DNS-сервер	BIND9, нативная установка
Режим DNS	Авторитетный сервер только для собственных OT-зон
Рекурсия	Отключена
Forwarder	Не используется
Контейнеризация	Не используется
Назначение ВМ	DNS, диагностика и системное администрирование
Веб-интерфейс администрирования	Webmin 2.653, HTTPS/TCP 10000, доступ только из management-сетей

Нативная установка выбрана намеренно: виртуальная машина уже обеспечивает изоляцию, а работа с несколькими IP-адресами, файлами зон, systemd, rndc и журналами DDNS .jnl остаётся прозрачной.

2.1. Авторитетный режим без рекурсии

Сервер отвечает только за зоны, перечисленные в /etc/bind/named.conf.local. Для внешних доменов, например ubuntu.com, сервер возвращает REFUSED.

OT-клиент → запрос имени из ot-samara.baltika.ru → локальный авторитетный ответ

OT-клиент → запрос внешнего имени             → REFUSED

Это исключает зависимость от внешнего DNS и не превращает OT-сервер в рекурсивный resolver.

3. План DNS-зон

3.1. Прямая зона

ot-samara.baltika.ru

Примеры имён оборудования:

plc-brew-001.ot-samara.baltika.ru

hmi-brew-001.ot-samara.baltika.ru

plc-fill-001.ot-samara.baltika.ru

hmi-util-001.ot-samara.baltika.ru

3.1.1. Именование многосетевых сервисов

Обычные одноинтерфейсные устройства сохраняют прежнюю схему HOST.ot-samara.baltika.ru. Для редких многосетевых серверов каждому OT-интерфейсу назначается отдельное имя, однозначно связанное с сегментом.

Сегмент	Метка	Пример FQDN
Legacy	legacy	smr-srv-ot-share.legacy.ot-samara.baltika.ru
Пивопроизводство	pivo	smr-srv-ot-share.pivo.ot-samara.baltika.ru
Розлив	rozliv	smr-srv-ot-share.rozliv.ot-samara.baltika.ru
Утилиты	utilities	smr-srv-ot-share.utilities.ot-samara.baltika.ru
АСТУЭ	astue	smr-srv-ot-share.astue.ot-samara.baltika.ru

Все эти owner name находятся внутри существующей зоны ot-samara.baltika.ru. Отдельные DNS-зоны для legacy/pivo/rozliv/utilities/astue не создаются.

Не создавать без отдельного проектного решения один owner HOST.ot-samara.baltika.ru сразу с A-записями всех интерфейсов многосетевого сервера: обычный DNS-клиент может выбрать адрес чужого сегмента. BIND Views для текущего небольшого количества многосетевых сервисов признаны избыточными.

3.2. Обратные зоны

IP-сеть	Назначение	Обратная DNS-зона
10.255.0.0/16	Legacy OT	255.10.in-addr.arpa
172.16.66.0/24	Пивопроизводство, первая половина /23	66.16.172.in-addr.arpa
172.16.67.0/24	Пивопроизводство, вторая половина /23	67.16.172.in-addr.arpa
172.16.68.0/24	Розлив, первая половина /23	68.16.172.in-addr.arpa
172.16.69.0/24	Розлив, вторая половина /23	69.16.172.in-addr.arpa
172.16.70.0/24	Утилиты, первая половина /23	70.16.172.in-addr.arpa
172.16.71.0/24	Утилиты, вторая половина /23	71.16.172.in-addr.arpa
172.17.14.0/24	АСТУЭ, VLAN 2006	14.17.172.in-addr.arpa

В домене in-addr.arpa октеты записываются в обратном порядке. Поэтому для сети 10.255.0.0/16 используется зона 255.10.in-addr.arpa, а не 10.255.in-addr.arpa.

Каждая сеть /23 состоит из двух соседних сетей /24, поэтому для неё создаются две стандартные обратные зоны.

4. Сетевая схема

4.1. Текущее состояние OT-сети

Сеть	VLAN	Состояние
10.255.0.0/16	VLAN 1	Действующая legacy-сеть
172.16.66.0/23	VLAN 1	Действующая производственная сеть

Обе подсети пока находятся в одном L2-домене и назначены одному интерфейсу Ubuntu.

4.2. Состояние после модернизации

Сеть	VLAN	Назначение	Локальный DNS-адрес	Шлюз OT-клиентов на firewall
172.16.66.0/23	2030	Пивопроизводство	172.16.66.53	172.16.67.254
172.16.68.0/23	2002	Розлив	172.16.68.53	172.16.69.254
172.16.70.0/23	2040	Утилиты	172.16.70.53	172.16.71.254
172.17.14.0/24	2006	АСТУЭ	172.17.14.53	172.17.14.254
10.255.0.0/16	1	Legacy OT на переходный период	10.255.0.53	10.255.255.254

Для сети /23 адрес шлюза находится во второй половине диапазона. Например, сеть 172.16.66.0/23 охватывает 172.16.66.0–172.16.67.255, поэтому проектный шлюз — 172.16.67.254.

4.3. Адреса управления

Этап	Адрес DNS-ВМ	Next-hop	Административные источники	Состояние
Развёртывание	192.168.1.53/24	192.168.1.1	192.168.1.0/24	Временное управление и доступ в Интернет; удаляется после завершения переноса
Production	10.44.100.228/24	10.44.100.1	10.44.0.0/21	SSH и Webmin подтверждены с 10.44.3.65 через маршрутизацию

Адрес 10.44.3.65/21 относится к сети 10.44.0.0/21 с маской 255.255.248.0. Именно адрес сети указывается в UFW, маршрутах и встроенном IP Access Control Webmin.

Целевой изолированный режим: после окончательного переноса у DNS-ВМ отсутствуют default route и системные upstream DNS. Адрес 10.44.100.1 используется только как next-hop для утверждённых статических маршрутов, например к 10.44.0.0/21 и внутренним NTP-серверам.

4.4. Разделение ролей DNS-сервера и firewall

DNS-ВМ многосетевая, но не является маршрутизатором:

net.ipv4.ip_forward = 0

net.ipv6.conf.all.forwarding = 0

Шлюзы .254 назначаются OT-клиентам и реализуются на отдельном firewall. На OT-интерфейсах DNS-ВМ шлюзы не задаются. Межсетевое взаимодействие разрешается выборочно правилами firewall, а сама DNS-ВМ остаётся конечным узлом.

После изоляции management-сети на DNS-ВМ также не используется default route. Возврат к маршрутизируемой административной сети и внутреннему NTP обеспечивается узкими статическими маршрутами через 10.44.100.1.

Для DNS и DDNS между OT-сетями не применять SNAT: BIND должен видеть фактический IP источника, поскольку allow-update, UFW и диагностика опираются на него.

5. Proxmox и интерфейсы виртуальной машины

5.1. Рабочая схема bridge

Ubuntu	MAC	Proxmox	Назначение	Адрес
ens18	BC:24:11:AE:75:CD	net0 / vmbr0	Временное управление	192.168.1.53/24
ens19	BC:24:11:DB:4F:A2	net1 / vmbr7 / nic1.2006	VLAN 2006, АСТУЭ	172.17.14.53/24
ens20	BC:24:11:6B:32:0E	net2 / vmbr3 / nic1.2002	VLAN 2002, Розлив	172.16.68.53/23
ens21	BC:24:11:E4:E6:A9	net3 / vmbr4 / nic1.2030	VLAN 2030, Пивопроизводство	Пока без IPv4; позднее 172.16.66.53/23
ens22	BC:24:11:32:D6:01	net4 / vmbr5 / nic1.2040	VLAN 2040, Утилиты	172.16.70.53/23
ens23	BC:24:11:D1:4C:AE	net5 / vmbr1 / nic1.2100	Production management	10.44.100.228/24
enp2s1	BC:24:11:7E:0F:4D	net6 / vmbr6 / nic2	Untagged access VLAN 1	10.255.0.53/16, 172.16.66.53/23

5.2. Почему VLAN 1 подключён через отдельный физический access-порт

Рабочий путь VLAN 1:

Коммутатор: access VLAN 1 / PVID 1

    ↓ untagged Ethernet

Proxmox nic2

    ↓

vmbr6

    ↓

VM net6

    ↓

Ubuntu enp2s1

Предыдущая схема nic1.1 → vmbr2 была удалена. Linux-подинтерфейс nic1.1 ожидает кадры с тегом VLAN 1, тогда как access/native VLAN 1 приходит без тега.

5.3. Подключение VLAN 2006 для АСТУЭ

Рабочий путь VLAN 2006:

Коммутатор: tagged VLAN 2006

    ↓

Proxmox nic1.2006

    ↓ тег снимается на Linux VLAN-интерфейсе

vmbr7

    ↓

VM net1, MAC BC:24:11:DB:4F:A2

    ↓ обычный нетегированный Ethernet внутри ВМ

Ubuntu ens19 → 172.17.14.53/24

VLAN-интерфейс внутри Ubuntu создавать не требуется. Тег 2006 обрабатывается Proxmox на nic1.2006, а гостевая система получает обычный виртуальный Ethernet-интерфейс ens19.

5.4. Состояние физического линка и виртуального интерфейса

Внутри ВМ интерфейс может показывать UP, LOWER_UP даже при отключённом кабеле nic2. Гостевая ОС видит виртуальный VirtIO/tap-порт, а не физический carrier хоста.

Физический линк проверяется на Proxmox:

ip -br link show nic2

cat /sys/class/net/nic2/carrier

ethtool nic2 | grep -E 'Speed:|Duplex:|Link detected:'

bridge link show master vmbr6

carrier = 0 означает отключённый физический линк, carrier = 1 — подключённый.

5.5. Правило миграции VLAN 2030

Адрес 172.16.66.53/23 нельзя одновременно назначать интерфейсам enp2s1 и ens21. Во время миграции он удаляется с VLAN 1 и в том же изменении назначается интерфейсу VLAN 2030.

6. Параметры виртуальной машины и установка Ubuntu

Ресурс	Значение
CPU	2 vCPU
RAM	4 ГБ
Диск	32 ГБ
Дисковый контроллер	VirtIO SCSI
Сетевые карты	VirtIO
QEMU Guest Agent	Включён в настройках ВМ

Параметры установщика:

hostname: smr-srv-ot-dns;

установить OpenSSH Server;

не устанавливать Docker и дополнительные snaps;

во время установки активировать только management-интерфейс;

на остальных интерфейсах отключить DHCP.

6.1. Установка hostname после первого входа

Даже если hostname уже задан установщиком, команда ниже приводит его к проектному значению и сразу показывает результат.

# hostnamectl меняет статическое имя узла через systemd-hostnamed.

sudo hostnamectl set-hostname smr-srv-ot-dns

# Проверяем короткое имя и полное состояние hostname.

hostname

hostnamectl status

7. Базовая подготовка Ubuntu

7.1. Обновление системы

sudo apt update

sudo apt full-upgrade -y

apt update обновляет индекс пакетов. apt full-upgrade устанавливает обновления и при необходимости корректно изменяет зависимости.

Перезагрузка выполняется только тогда, когда система её запросила. Проверка:

# -f проверяет существование обычного файла.

if [ -f /var/run/reboot-required ]; then

  cat /var/run/reboot-required.pkgs

  systemctl reboot

fi

После загрузки повторно проверяются сеть, named, webmin, конфигурация зон и контрольные запросы dig. Конкретный пакет, который потребовал reboot на отдельной установке, для универсальной инструкции несущественен.

7.2. Базовые пакеты

sudo apt install -y \

  ca-certificates \

  curl \

  nano \

  openssl \

  iputils-ping \

  tcpdump \

  arping \

  bash-completion \

  lsof \

  qemu-guest-agent \

  systemd-timesyncd \

  ufw

Пакет	Назначение
ca-certificates	Проверка TLS-сертификатов
curl	Проверка HTTP/HTTPS и получение файлов
nano	Редактирование конфигурационных файлов
openssl	Криптографические операции и диагностика TLS
iputils-ping	Проверка IP-доступности
tcpdump	Анализ DNS, ARP, ICMP и NTP-трафика
arping	Проверка адресных конфликтов и L2-доступности
bash-completion	Автодополнение команд
lsof	Поиск процессов, использующих файлы и порты
qemu-guest-agent	Интеграция Ubuntu с Proxmox
systemd-timesyncd	Синхронизация системного времени
ufw	Host firewall

8. QEMU Guest Agent

systemctl status qemu-guest-agent --no-pager

ls -l /dev/virtio-ports/

Ожидается:

Active: active (running)

/dev/virtio-ports/org.qemu.guest_agent.0

Служба может иметь тип static. Это нормально: она запускается при наличии virtio-канала, созданного Proxmox.

9. Часовой пояс и NTP

9.1. Часовой пояс

sudo timedatectl set-timezone Europe/Samara

sudo timedatectl set-local-rtc 0

sudo timedatectl set-ntp true

9.2. Временный NTP

sudo install -d -m 0755 /etc/systemd/timesyncd.conf.d

sudo tee /etc/systemd/timesyncd.conf.d/10-internal-ntp.conf >/dev/null <<'EOF'

[Time]

NTP=ntp.ubuntu.com

FallbackNTP=

EOF

sudo systemctl restart systemd-timesyncd

9.3. Проверка

timedatectl status

timedatectl timesync-status

systemctl status systemd-timesyncd --no-pager

journalctl -u systemd-timesyncd --since "5 minutes ago" --no-pager

Подтверждённое состояние: часы синхронизированы, источник ntp.ubuntu.com, stratum 2.

9.4. Production NTP

После отключения Интернета используются только внутренние NTP-серверы:

10.44.14.34

10.44.14.33

При отсутствии default route к каждому серверу задаётся точный маршрут /32 через 10.44.100.1, а в UFW разрешается исходящий UDP/123.

[Time]

NTP=10.44.14.34 10.44.14.33

FallbackNTP=

Публичные NTP-имена и DNS-разрешение для этой задачи не требуются.

10. Netplan

10.1. Отключение управления сетью со стороны cloud-init

sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg >/dev/null <<'EOF'

network: {config: disabled}

EOF

sudo mv /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.disabled

10.2. Актуальный файл /etc/netplan/01-ot-dns.yaml

Создаём файл целиком одной командой:

# tee получает текст из heredoc и полностью записывает файл Netplan.

# Кавычки в <<'EOF' запрещают shell подставлять переменные внутри YAML.

sudo tee /etc/netplan/01-ot-dns.yaml >/dev/null <<'EOF'

network:

  version: 2

  renderer: networkd

  ethernets:

    # Временная management-сеть и единственный действующий default route.

    ens18:

      dhcp4: false

      dhcp6: false

      addresses:

        - 192.168.1.53/24

      nameservers:

        addresses:

          - 192.168.1.1

      routes:

        - to: default

          via: 192.168.1.1

    # АСТУЭ, VLAN 2006 через Proxmox vmbr7 / nic1.2006.

    ens19:

      dhcp4: false

      dhcp6: false

      accept-ra: false

      link-local: []

      optional: true

      addresses:

        - 172.17.14.53/24

    # Legacy OT и временное Пивопроизводство в untagged VLAN 1.

    enp2s1:

      dhcp4: false

      dhcp6: false

      accept-ra: false

10.3. Безопасное применение

sudo chmod 600 /etc/netplan/01-ot-dns.yaml

sudo netplan generate

sudo netplan try --timeout 120

netplan try временно применяет конфигурацию и автоматически откатывает её, если администратор не подтвердит изменения.

10.4. Подтверждённое состояние

ens18   192.168.1.53/24

ens19   172.17.14.53/24

enp2s1  10.255.0.53/16 172.16.66.53/23

ens20   172.16.68.53/23

ens21   без IPv4

ens22   172.16.70.53/23

ens23   10.44.100.228/24

Активный маршрут по умолчанию:

default via 192.168.1.1 dev ens18

Проверена доступность production management: 10.44.100.225, 10.44.100.1 и 10.44.100.210 отвечают через ens23. Для АСТУЭ подтверждён связанный маршрут 172.17.14.0/24 dev ens19 src 172.17.14.53; единственный default route остался через ens18.

Дополнительно подтверждена маршрутизируемая доступность адреса 10.44.100.228 с административного узла 10.44.3.65 по TCP/22 и TCP/10000 после разрешения сети 10.44.0.0/21 в UFW. Окончательное удаление временного default route и ens18 выполняется отдельным контролируемым этапом.

10.5. Перенос в production management без доступа в Интернет

Цель этапа — оставить сервер без default route и без системных DNS-серверов Ubuntu, сохранив только явные маршруты к административной сети и внутреннему NTP.

Перед применением открыть консоль ВМ в Proxmox и подключиться к Webmin именно по https://10.44.100.228:10000. Изменения применять через netplan try.

Целевые блоки Netplan:

    # Временный интерфейс сохраняется только на переходный период.

    # После окончательной проверки адрес и сам vNIC можно удалить.

    ens18:

      dhcp4: false

      dhcp6: false

      addresses:

        - 192.168.1.53/24

      # nameservers отсутствуют

      # default route отсутствует

    ens23:

      dhcp4: false

      dhcp6: false

      accept-ra: false

      link-local: []

      optional: true

      addresses:

        - 10.44.100.228/24

      routes:

        - to: 10.44.0.0/21

          via: 10.44.100.1

        - to: 10.44.14.33/32

          via: 10.44.100.1

        - to: 10.44.14.34/32

          via: 10.44.100.1

Применение и контроль:

sudo cp -a /etc/netplan/01-ot-dns.yaml   "/root/01-ot-dns.yaml.before-prod-isolation-$(date +%F-%H%M%S)"

sudo chmod 600 /etc/netplan/01-ot-dns.yaml

sudo netplan generate

sudo netplan try --timeout 120

ip -4 route show default

ip route get 10.44.3.65

ip route get 10.44.14.33

ip route get 10.44.14.34

ip route get 1.1.1.1

Ожидается: вывод ip -4 route show default пустой; адрес 10.44.3.65 и NTP-серверы идут через ens23; для 1.1.1.1 возвращается Network is unreachable.

systemd-resolved отключать не требуется. В /etc/resolv.conf может оставаться локальный stub 127.0.0.53, но upstream DNS после удаления блока nameservers отсутствует.

11. Запрет маршрутизации и UFW

11.1. IP forwarding

sudo tee /etc/sysctl.d/90-ot-dns-no-forwarding.conf >/dev/null <<'EOF'

net.ipv4.ip_forward=0

net.ipv6.conf.all.forwarding=0

EOF

sudo sysctl --system

Проверка:

sysctl net.ipv4.ip_forward

sysctl net.ipv6.conf.all.forwarding

11.2. Текущие правила UFW

sudo ufw default deny incoming

sudo ufw default allow outgoing

sudo ufw default deny routed

# Временный management-доступ на период переноса.

sudo ufw allow in on ens18 proto tcp   from 192.168.1.0/24 to 192.168.1.53 port 22   comment 'SSH temporary management network'

# Production SSH из маршрутизируемой административной сети.

sudo ufw allow in on ens23 proto tcp   from 10.44.0.0/21 to 10.44.100.228 port 22   comment 'SSH management 10.44.0.0/21'

# Production Webmin из той же административной сети.

sudo ufw allow in on ens23 proto tcp   from 10.44.0.0/21 to 10.44.100.228 port 10000   comment 'Webmin management 10.44.0.0/21'

sudo ufw enable

sudo ufw reload

sudo ufw status numbered

Подтверждённый административный клиент 10.44.3.65 входит в сеть 10.44.0.0/21. После добавления правил SSH и HTTPS/Webmin стали доступны через ens23.

# Проверка обратного маршрута и слушающих служб.

ip route get 10.44.3.65

ss -lntp | grep -E ':(22|10000)'

systemctl is-active ssh

systemctl is-active webmin

Ожидаемый маршрут после окончательной изоляции:

10.44.3.65 via 10.44.100.1 dev ens23 src 10.44.100.228

Ping не подтверждает доступ к SSH или Webmin: ICMP и TCP фильтруются разными правилами. При работающем ping и тайм-ауте TCP сначала проверяются UFW, слушающие сокеты и фактический source IP.

11.3. DNS-правила UFW — применены

Для каждого DNS-адреса разрешены оба штатных транспортных протокола DNS: UDP/53 и TCP/53. Правила ограничены одновременно входным интерфейсом, сетью источника, адресом назначения и портом.

Сеть клиентов	Входной интерфейс	DNS-адрес	Состояние
10.255.0.0/16	enp2s1	10.255.0.53	Действующее правило VLAN 1
172.16.66.0/23	enp2s1	172.16.66.53	Действующее временное правило VLAN 1
172.16.68.0/23	ens20	172.16.68.53	Действующее правило VLAN 2002
172.16.70.0/23	ens22	172.16.70.53	Действующее правило VLAN 2040
172.16.66.0/23	ens21	172.16.66.53	Подготовлено для будущего VLAN 2030
172.17.14.0/24	ens19	172.17.14.53	Действующее правило VLAN 2006, АСТУЭ

# Legacy OT, VLAN 1

sudo ufw allow in on enp2s1 proto udp \

  from 10.255.0.0/16 to 10.255.0.53 port 53 \

  comment 'DNS legacy OT UDP'

sudo ufw allow in on enp2s1 proto tcp \

  from 10.255.0.0/16 to 10.255.0.53 port 53 \

  comment 'DNS legacy OT TCP'

# Пивопроизводство, временно VLAN 1

sudo ufw allow in on enp2s1 proto udp \

  from 172.16.66.0/23 to 172.16.66.53 port 53 \

  comment 'DNS beer production current VLAN1 UDP'

sudo ufw allow in on enp2s1 proto tcp \

  from 172.16.66.0/23 to 172.16.66.53 port 53 \

  comment 'DNS beer production current VLAN1 TCP'

# Розлив, VLAN 2002

sudo ufw allow in on ens20 proto udp \

  from 172.16.68.0/23 to 172.16.68.53 port 53 \

  comment 'DNS bottling VLAN2002 UDP'

sudo ufw allow in on ens20 proto tcp \

  from 172.16.68.0/23 to 172.16.68.53 port 53 \

  comment 'DNS bottling VLAN2002 TCP'

# Утилиты, VLAN 2040

sudo ufw allow in on ens22 proto udp \

  from 172.16.70.0/23 to 172.16.70.53 port 53 \

  comment 'DNS utilities VLAN2040 UDP'

sudo ufw allow in on ens22 proto tcp \

  from 172.16.70.0/23 to 172.16.70.53 port 53 \

  comment 'DNS utilities VLAN2040 TCP'

Правила на ens21 не переносят IP-адрес и не создают прослушивающий сокет. Пока 172.16.66.53/23 находится на enp2s1, они фактически бездействуют. После миграции адреса в VLAN 2030 они начнут применяться автоматически.

После окончательной миграции два старых правила для 172.16.66.53 на enp2s1 необходимо удалить. Порт 53 на management-интерфейсах ens18 и ens23 не открывается.

12. Установка BIND9

sudo apt update

sudo apt install -y bind9 bind9-utils dnsutils

Пакет	Назначение
bind9	Служба named
bind9-utils	named-checkconf, named-checkzone, rndc
dnsutils	dig, host, nslookup

Подтверждённая версия на момент установки:

BIND 9.18.39-0ubuntu0.24.04.5-Ubuntu

bind9.service является alias для основной службы named.service. Поэтому журнал удобнее смотреть через journalctl -u named.

12.1. Резервная копия исходной конфигурации

backup_dir="/root/bind9-before-configuration-$(date +%F-%H%M%S)"

sudo mkdir -m 0700 "$backup_dir"

sudo cp -a /etc/bind "$backup_dir/"

sudo tar -C "$backup_dir" -czf "${backup_dir}.tar.gz" bind

sudo sha256sum "${backup_dir}.tar.gz"

13. Глобальная конфигурация BIND

13.1. Главный файл /etc/bind/named.conf

Главный файл не содержит зон напрямую: он подключает три отдельных файла. Это штатная структура пакета BIND9 в Ubuntu.

# Полностью записываем главный конфигурационный файл BIND.

sudo tee /etc/bind/named.conf >/dev/null <<'EOF'

include "/etc/bind/named.conf.options";

include "/etc/bind/named.conf.local";

include "/etc/bind/named.conf.default-zones";

EOF

13.2. Файл /etc/bind/named.conf.options

# Создаём ACL клиентов и полный блок options.

sudo tee /etc/bind/named.conf.options >/dev/null <<'EOF'

// Сети, которым разрешено обращаться к авторитетным OT-зонам.

acl "ot-clients" {

    localhost;

    10.255.0.0/16;      // Legacy OT, VLAN 1.

    172.16.66.0/23;     // Пивопроизводство: VLAN 1, позднее VLAN 2030.

    172.16.68.0/23;     // Розлив, VLAN 2002.

    172.16.70.0/23;     // Утилиты, VLAN 2040.

    172.17.14.0/24;     // АСТУЭ, VLAN 2006.

};

options {

    directory "/var/cache/bind";

    // BIND слушает localhost и только сервисные OT-адреса.

    // Management-адреса 192.168.1.53 и 10.44.100.228 сюда не входят.

    listen-on {

        127.0.0.1;

        10.255.0.53;    // Legacy OT, VLAN 1.

        172.16.66.53;   // Пивопроизводство.

        172.16.68.53;   // Розлив, VLAN 2002.

        172.16.70.53;   // Утилиты, VLAN 2040.

        172.17.14.53;   // АСТУЭ, VLAN 2006.

    };

    listen-on-v6 { none; };

    allow-query { ot-clients; };

    // Сервер является только авторитетным и не разрешает внешние имена.

    recursion no;

    allow-query-cache { none; };

    dnssec-validation no;

    // Secondary DNS пока отсутствует.

13.3. Смысл ключевых параметров

Параметр	Назначение
acl "ot-clients"	Перечень сетей, которым разрешены DNS-запросы
listen-on	Точные локальные адреса, на которых BIND открывает TCP/UDP 53
listen-on-v6 { none; }	Запрет DNS-прослушивания по IPv6
allow-query	Кто может спрашивать записи авторитетных зон
recursion no	Не разрешать внешние имена через другие DNS-серверы
allow-query-cache { none; }	Не предоставлять клиентам рекурсивный кэш
dnssec-validation no	Валидация рекурсивных ответов не нужна, потому что рекурсия отключена
allow-transfer { none; }	Запрет AXFR/IXFR до появления secondary DNS
version "not disclosed"	Не публиковать точную версию в version.bind

В конфигурации намеренно отсутствуют:

# В действующей конфигурации эти директивы должны отсутствовать.

# Пустой вывод означает, что forwarder не настроен.

grep -RniE '^\s*(forwarders|forward only|forward first)\b' /etc/bind

13.4. Проверка и перечитывание

sudo named-checkconf

sudo rndc reconfig

sudo rndc flush

systemctl is-active named

Внешний запрос должен быстро получить отказ:

dig @127.0.0.1 ubuntu.com A +norecurse

Ожидается status: REFUSED.

14. Файлы зон

14.1. Каталог зон

sudo install -d -o bind -g bind -m 0750 /var/lib/bind/zones

Каталог размещён в /var/lib/bind, потому что BIND создаёт здесь журналы динамических обновлений .jnl.

14.2. Прямая зона

Прямая зона динамическая. Ниже приведён воспроизводимый базовый файл без временных клиентских записей. После запуска DDNS фактический serial и клиентские A-записи могут быть выше и находиться в .jnl до выполнения rndc sync.

# Полностью создаём базовый файл прямой зоны.

sudo tee /var/lib/bind/zones/db.ot-samara.baltika.ru >/dev/null <<'EOF'

$ORIGIN ot-samara.baltika.ru.

$TTL 3600

@   IN  SOA smr-srv-ot-dns.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (

        2026073100

        3600

        900

        1209600

        300

)

@                   IN  NS      smr-srv-ot-dns.ot-samara.baltika.ru.

; Фактическое имя многосетевого DNS-сервера.

smr-srv-ot-dns     IN  A       10.255.0.53

smr-srv-ot-dns     IN  A       172.16.66.53

smr-srv-ot-dns     IN  A       172.16.68.53

smr-srv-ot-dns     IN  A       172.16.70.53

smr-srv-ot-dns     IN  A       172.17.14.53

; Однозначные имена primary для reverse-зон.

ns-10-255          1200 IN A    10.255.0.53

ns-172-16-66       1200 IN A    172.16.66.53

ns-172-16-68       1200 IN A    172.16.68.53

ns-172-16-70       1200 IN A    172.16.70.53

ns-172-17-14       1200 IN A    172.17.14.53

dns                 IN  CNAME   smr-srv-ot-dns

EOF

sudo chown bind:bind /var/lib/bind/zones/db.ot-samara.baltika.ru

sudo chmod 0640 /var/lib/bind/zones/db.ot-samara.baltika.ru

Имя smr-srv-ot-dns сохраняет пять сервисных адресов и остаётся SOA/NS прямой зоны. Имена ns-* предназначены для reverse-зон и каждое имеет строго одну A-запись, доступную клиентам соответствующей сети.

Serial в динамической зоне: не копировать наблюдаемый serial из этой инструкции поверх работающей зоны. Перед изменением выполнять rndc freeze либо использовать Webmin, который выполняет защитный цикл автоматически.

14.3. Контакт администратора в SOA

Во всех девяти зонах используется одно фактическое значение RNAME:

hostmaster.ot-samara.baltika.ru.

В DNS-формате первая точка заменяет символ @, поэтому значение соответствует адресу hostmaster@ot-samara.baltika.ru. BIND не отправляет на него почту автоматически. Изменение контакта является изменением данных зоны и требует увеличения SOA serial, проверки named-checkzone и перечитывания зоны.

14.4. Обратные зоны

Все обратные зоны динамические. Для каждой сети используется локальное имя primary с единственной A-записью. Это устраняет неоднозначность выбора адреса сервером DNS Client Windows.

Reverse-зона	SOA MNAME и NS	A primary
255.10.in-addr.arpa	ns-10-255.ot-samara.baltika.ru.	10.255.0.53
66.16.172.in-addr.arpa, 67.16.172.in-addr.arpa	ns-172-16-66.ot-samara.baltika.ru.	172.16.66.53
68.16.172.in-addr.arpa, 69.16.172.in-addr.arpa	ns-172-16-68.ot-samara.baltika.ru.	172.16.68.53
70.16.172.in-addr.arpa, 71.16.172.in-addr.arpa	ns-172-16-70.ot-samara.baltika.ru.	172.16.70.53
14.17.172.in-addr.arpa	ns-172-17-14.ot-samara.baltika.ru.	172.17.14.53

14.4.1. /var/lib/bind/zones/db.255.10

# Legacy OT: 10.255.0.0/16, VLAN 1.

sudo tee /var/lib/bind/zones/db.255.10 >/dev/null <<'EOF'

$TTL 3600

@   IN SOA ns-10-255.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (

        2026073100

        3600

        900

        1209600

        300

)

@   IN NS ns-10-255.ot-samara.baltika.ru.

53.0  IN PTR smr-srv-ot-dns.ot-samara.baltika.ru.

EOF

14.4.2. /var/lib/bind/zones/db.66.16.172

# Пивопроизводство: 172.16.66.0/24.

sudo tee /var/lib/bind/zones/db.66.16.172 >/dev/null <<'EOF'

$TTL 3600

@   IN SOA ns-172-16-66.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (

        2026073100

        3600

        900

        1209600

        300

)

@   IN NS ns-172-16-66.ot-samara.baltika.ru.

53    IN PTR smr-srv-ot-dns.ot-samara.baltika.ru.

EOF

14.4.3. /var/lib/bind/zones/db.67.16.172

# Пивопроизводство: 172.16.67.0/24, вторая половина /23.

sudo tee /var/lib/bind/zones/db.67.16.172 >/dev/null <<'EOF'

$TTL 3600

@   IN SOA ns-172-16-66.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (

        2026073100

        3600

        900

        1209600

        300

)

@   IN NS ns-172-16-66.ot-samara.baltika.ru.

; Клиентские PTR создаются динамически или вручную через Webmin.

EOF

14.4.4. /var/lib/bind/zones/db.68.16.172

# Розлив: 172.16.68.0/24, VLAN 2002.

sudo tee /var/lib/bind/zones/db.68.16.172 >/dev/null <<'EOF'

$TTL 3600

@   IN SOA ns-172-16-68.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (

        2026073100

        3600

        900

        1209600

        300

)

@   IN NS ns-172-16-68.ot-samara.baltika.ru.

53    IN PTR smr-srv-ot-dns.ot-samara.baltika.ru.

EOF

14.4.5. /var/lib/bind/zones/db.69.16.172

# Розлив: 172.16.69.0/24, вторая половина /23.

sudo tee /var/lib/bind/zones/db.69.16.172 >/dev/null <<'EOF'

$TTL 3600

@   IN SOA ns-172-16-68.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (

        2026073100

        3600

        900

        1209600

        300

)

@   IN NS ns-172-16-68.ot-samara.baltika.ru.

; Клиентские PTR создаются динамически или вручную через Webmin.

EOF

14.4.6. /var/lib/bind/zones/db.70.16.172

# Утилиты: 172.16.70.0/24, VLAN 2040.

sudo tee /var/lib/bind/zones/db.70.16.172 >/dev/null <<'EOF'

$TTL 3600

@   IN SOA ns-172-16-70.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (

        2026073100

        3600

        900

        1209600

        300

)

@   IN NS ns-172-16-70.ot-samara.baltika.ru.

53    IN PTR smr-srv-ot-dns.ot-samara.baltika.ru.

EOF

14.4.7. /var/lib/bind/zones/db.71.16.172

# Утилиты: 172.16.71.0/24, вторая половина /23.

sudo tee /var/lib/bind/zones/db.71.16.172 >/dev/null <<'EOF'

$TTL 3600

@   IN SOA ns-172-16-70.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (

        2026073100

        3600

        900

        1209600

        300

)

@   IN NS ns-172-16-70.ot-samara.baltika.ru.

; Клиентские PTR создаются динамически или вручную через Webmin.

EOF

14.4.8. /var/lib/bind/zones/db.14.17.172

# АСТУЭ: 172.17.14.0/24, VLAN 2006.

sudo tee /var/lib/bind/zones/db.14.17.172 >/dev/null <<'EOF'

$TTL 3600

@   IN SOA ns-172-17-14.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (

        2026073100

        3600

        900

        1209600

        300

)

@   IN NS ns-172-17-14.ot-samara.baltika.ru.

53    IN PTR smr-srv-ot-dns.ot-samara.baltika.ru.

EOF

14.4.9. Владелец и права всех файлов зон

sudo chown bind:bind /var/lib/bind/zones/db.*

sudo chmod 0640 /var/lib/bind/zones/db.*

После получения DDNS в текстовых файлах могут появиться A/PTR только после rndc sync. Live-ответ dig является первичной проверкой; Webmin и grep по файлу — проверкой после синхронизации.

14.5. Файл /etc/bind/named.conf.local

# Полностью объявляем одну прямую и восемь обратных динамических зон.

sudo tee /etc/bind/named.conf.local >/dev/null <<'EOF'

zone "ot-samara.baltika.ru" {

    type master;

    file "/var/lib/bind/zones/db.ot-samara.baltika.ru";

    allow-update {

        10.255.0.0/16;

        172.16.66.0/23;

        172.16.68.0/23;

        172.16.70.0/23;

        172.17.14.0/24;

    };

    notify no;

};

zone "255.10.in-addr.arpa" {

    type master;

    file "/var/lib/bind/zones/db.255.10";

    allow-update { 10.255.0.0/16; };

    notify no;

};

zone "66.16.172.in-addr.arpa" {

    type master;

    file "/var/lib/bind/zones/db.66.16.172";

    allow-update { 172.16.66.0/23; };

    notify no;

};

zone "67.16.172.in-addr.arpa" {

    type master;

    file "/var/lib/bind/zones/db.67.16.172";

    allow-update { 172.16.66.0/23; };

    notify no;

};

allow-update в прямой зоне допускает регистрацию A из всех проектных OT-сетей. В каждой reverse-зоне разрешена только соответствующая сеть; для пары зон одной сети /23 используется общий ACL /23.

Модель доверия: ACL по IP не удостоверяет личность клиента. В текущем изолированном OT-контуре это принято как рабочий этап, но не заменяет TSIG/GSS-TSIG.

15. Основные DNS-записи — расшифровка

Учебный раздел: короткие записи ниже объясняют типы RR и не заменяют проектные файлы. Полные фактические зоны для копирования приведены в разделе 14.

15.1. Общий формат

ИМЯ  TTL  КЛАСС  ТИП  ЗНАЧЕНИЕ

Элемент	Смысл
$ORIGIN	Базовый суффикс, который BIND добавляет к коротким именам
$TTL	Время хранения ответа в кэше, в секундах
@	Вершина текущей зоны, то есть значение $ORIGIN
IN	Класс Internet, используемый для обычных DNS-записей
Точка в конце имени	Имя полное; $ORIGIN дописывать не нужно

15.2. SOA — паспорт зоны

SOA означает Start of Authority. Запись описывает конкретную зону:

MNAME — primary DNS-сервер зоны;

RNAME — контакт ответственного администратора;

serial — версия зоны;

refresh — как часто secondary проверяет serial;

retry — через сколько повторить неудачную проверку;

expire — когда secondary перестаёт считать старую копию действительной;

negative cache TTL — сколько кэшировать ответ об отсутствии имени.

15.3. NS — серверы зоны

NS означает Name Server. Запись перечисляет авторитетные DNS-серверы, которые обслуживают зону.

@ IN NS smr-srv-ot-dns.ot-samara.baltika.ru.

SOA у зоны одна, а NS-записей может быть несколько.

15.4. A и AAAA

A связывает имя с IPv4-адресом:

plc-001 IN A 172.16.66.100

AAAA является IPv6-аналогом A. В проекте IPv6 для DNS-службы не используется.

15.5. CNAME

CNAME создаёт псевдоним другого DNS-имени:

dns IN CNAME smr-srv-ot-dns

Имя, являющееся CNAME, не должно одновременно иметь A, PTR, MX и другие обычные записи.

15.6. PTR

PTR связывает IP-адрес с DNS-именем. Команда dig -x автоматически формирует обратное имя в in-addr.arpa.

172.16.66.53

→ 53.66.16.172.in-addr.arpa

→ smr-srv-ot-dns.ot-samara.baltika.ru.

15.7. MX

MX означает Mail Exchanger — сервер, принимающий электронную почту для домена.

@     IN MX 10 mail1.ot-samara.baltika.ru.

@     IN MX 20 mail2.ot-samara.baltika.ru.

mail1 IN A     172.16.66.25

mail2 IN A     172.16.66.26

Чем меньше число, тем выше приоритет. MX указывает на DNS-имя, а не на IP-адрес. Для текущей OT-зоны MX не нужен, поскольку она не предназначена для приёма почты.

16. Проверка конфигурации и зон

16.1. Проверка отдельной зоны

Каждое имя зоны проверяется вместе с конкретным файлом. Успешный результат для каждой команды заканчивается строкой OK.

# Прямая зона.

sudo named-checkzone ot-samara.baltika.ru /var/lib/bind/zones/db.ot-samara.baltika.ru

# Legacy OT.

sudo named-checkzone 255.10.in-addr.arpa /var/lib/bind/zones/db.255.10

# Пивопроизводство, две /24 зоны.

sudo named-checkzone 66.16.172.in-addr.arpa /var/lib/bind/zones/db.66.16.172

sudo named-checkzone 67.16.172.in-addr.arpa /var/lib/bind/zones/db.67.16.172

# Розлив, две /24 зоны.

sudo named-checkzone 68.16.172.in-addr.arpa /var/lib/bind/zones/db.68.16.172

sudo named-checkzone 69.16.172.in-addr.arpa /var/lib/bind/zones/db.69.16.172

# Утилиты, две /24 зоны.

sudo named-checkzone 70.16.172.in-addr.arpa /var/lib/bind/zones/db.70.16.172

sudo named-checkzone 71.16.172.in-addr.arpa /var/lib/bind/zones/db.71.16.172

# АСТУЭ.

sudo named-checkzone 14.17.172.in-addr.arpa /var/lib/bind/zones/db.14.17.172

16.2. Проверка всей конфигурации и загрузки зон

sudo named-checkconf

sudo named-checkconf -z

named-checkconf проверяет синтаксис конфигурации. Ключ -z дополнительно пытается загрузить все primary-зоны.

16.3. Запуск и состояние

sudo systemctl start named

systemctl is-active named

sudo rndc status

sudo journalctl -u named --since "3 minutes ago" --no-pager

Подтверждённое состояние:

number of zones: 14

server is up and running

query logging is OFF

recursive clients: 0

Число 14 складывается из девяти созданных зон — одной прямой и восьми обратных, — четырёх стандартных localhost-зон Ubuntu и одной служебной managed-keys zone.

17. Проверка через dig

17.1. SOA

dig @127.0.0.1 ot-samara.baltika.ru SOA +norecurse

17.2. NS

dig @127.0.0.1 ot-samara.baltika.ru NS +norecurse

17.3. A и CNAME

dig @127.0.0.1 smr-srv-ot-dns.ot-samara.baltika.ru A +norecurse

dig @127.0.0.1 dns.ot-samara.baltika.ru A +norecurse

17.4. PTR

dig @127.0.0.1 -x 10.255.0.53 +norecurse

dig @127.0.0.1 -x 172.16.66.53 +norecurse

dig @127.0.0.1 -x 172.16.68.53 +norecurse

dig @127.0.0.1 -x 172.16.70.53 +norecurse

dig @127.0.0.1 -x 172.17.14.53 +norecurse

17.5. Проверка через сервисный адрес АСТУЭ

dig @172.17.14.53 smr-srv-ot-dns.ot-samara.baltika.ru A +norecurse

dig @172.17.14.53 dns.ot-samara.baltika.ru A +norecurse

dig @172.17.14.53 -x 172.17.14.53 +norecurse

dig @172.17.14.53 14.17.172.in-addr.arpa SOA +tcp +norecurse

Фактически получено: пять A-записей; одна CNAME и пять A-записей; корректный PTR; актуальный SOA reverse-зоны. Все ответы имеют NOERROR и флаг aa.2026072702. Все ответы имеют NOERROR и флаг aa.

17.6. Внешнее имя

dig @127.0.0.1 ubuntu.com A +norecurse

Ожидаемая логика:

собственные зоны → status: NOERROR, флаг aa

внешние зоны     → status: REFUSED

17.7. Основные элементы вывода dig

Поле или флаг	Смысл
NOERROR	Запрос обработан без ошибки
NXDOMAIN	Такого имени не существует
REFUSED	Политика сервера запрещает запрос
SERVFAIL	Сервер не смог обработать запрос
qr	Пакет является ответом
aa	Авторитетный ответ из собственной зоны
rd	Клиент запросил рекурсию
ra	Сервер предоставляет рекурсию; в данном проекте отсутствует
QUESTION	Что было запрошено
ANSWER	Непосредственный ответ
AUTHORITY	Информация об авторитетной зоне
ADDITIONAL	Дополнительные полезные записи и EDNS OPT

18. Проверка firewall, локальных DNS-сокетов и end-to-end

18.1. Проверка firewall и локальных DNS-сокетов

sudo ufw status numbered

sudo ufw show added

systemctl is-active named

sudo ss -lntup | grep named

sudo journalctl -u named --since "10 minutes ago" --no-pager

Подтверждено: UFW активен, правила применены, служба named активна и слушает OT-адреса по UDP и TCP.

Локально успешно выполнены следующие проверки:

# UDP через сервисный адрес VLAN 1

dig @10.255.0.53 ot-samara.baltika.ru SOA +norecurse

# TCP через сервисный адрес VLAN 1

dig @10.255.0.53 ot-samara.baltika.ru SOA +tcp +norecurse

# UDP через сервисный адрес VLAN 2002

dig @172.16.68.53 ot-samara.baltika.ru SOA +norecurse

# UDP через сервисный адрес АСТУЭ, VLAN 2006

dig @172.17.14.53 ot-samara.baltika.ru SOA +norecurse

# TCP через сервисный адрес АСТУЭ, VLAN 2006

dig @172.17.14.53 14.17.172.in-addr.arpa SOA +tcp +norecurse

Ожидаемые и фактически полученные признаки:

status: NOERROR

flags: qr aa

Ограничение локальной проверки: запрос к собственному IP-адресу сервера обрабатывается ядром как локальный маршрут и не доказывает прохождение пакета через физический OT-интерфейс, VLAN и интерфейсное правило UFW. Полная end-to-end-проверка выполняется только с отдельного хоста соответствующей OT-сети.

Проверка BIND через каждый конкретный сервисный адрес. Здесь запрос выполняется локально на сервере; он проверяет сокет BIND и зону, но не заменяет end-to-end-тест с удалённого клиента.

# Legacy OT, VLAN 1.

dig @10.255.0.53 ot-samara.baltika.ru SOA +norecurse

dig @10.255.0.53 ot-samara.baltika.ru SOA +tcp +norecurse

# Пивопроизводство, сейчас VLAN 1.

dig @172.16.66.53 ot-samara.baltika.ru SOA +norecurse

dig @172.16.66.53 ot-samara.baltika.ru SOA +tcp +norecurse

# Розлив, VLAN 2002.

dig @172.16.68.53 ot-samara.baltika.ru SOA +norecurse

dig @172.16.68.53 ot-samara.baltika.ru SOA +tcp +norecurse

# Утилиты, VLAN 2040.

dig @172.16.70.53 ot-samara.baltika.ru SOA +norecurse

dig @172.16.70.53 ot-samara.baltika.ru SOA +tcp +norecurse

# АСТУЭ, VLAN 2006.

dig @172.17.14.53 ot-samara.baltika.ru SOA +norecurse

dig @172.17.14.53 ot-samara.baltika.ru SOA +tcp +norecurse

18.2. End-to-end-проверка с OT-клиентов — выполнена

Каждый блок выполняется в PowerShell на Windows-клиенте, физически подключённом к указанной сети. Проверяются авторитетный A-ответ, PTR локального DNS-адреса, DNS по TCP и доступность TCP/53. Параметр -DnsOnly исключает LLMNR/NetBIOS, а -TcpOnly принудительно использует DNS over TCP.

Сеть	Назначение	DNS-адрес	Результат
10.255.0.0/16	Legacy OT, VLAN 1	10.255.0.53	A/PTR/UDP/TCP успешно
172.16.66.0/23	Пивопроизводство, временно VLAN 1	172.16.66.53	A/PTR/UDP/TCP успешно
172.16.68.0/23	Розлив, VLAN 2002	172.16.68.53	A/PTR/UDP/TCP успешно
172.16.70.0/23	Утилиты, VLAN 2040	172.16.70.53	A/PTR/UDP/TCP успешно
172.17.14.0/24	АСТУЭ, VLAN 2006	172.17.14.53	A/PTR/UDP/TCP успешно

18.2.1. Legacy OT — 10.255.0.0/16, VLAN 1

# Прямая запись: имя DNS-сервера должно вернуть RRset из пяти A-адресов.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 10.255.0.53 `

  -DnsOnly

# Обратная запись: локальный DNS-адрес должен вернуть имя сервера.

Resolve-DnsName `

  -Name 10.255.0.53 `

  -Type PTR `

  -Server 10.255.0.53 `

  -DnsOnly

# Содержательная проверка DNS по TCP.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 10.255.0.53 `

  -DnsOnly `

  -TcpOnly

# Проверка установки TCP-соединения на порт 53.

Test-NetConnection `

  -ComputerName 10.255.0.53 `

  -Port 53 `

  -InformationLevel Detailed

18.2.2. Пивопроизводство — 172.16.66.0/23, временно VLAN 1

# Прямая запись: имя DNS-сервера должно вернуть RRset из пяти A-адресов.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 172.16.66.53 `

  -DnsOnly

# Обратная запись: локальный DNS-адрес должен вернуть имя сервера.

Resolve-DnsName `

  -Name 172.16.66.53 `

  -Type PTR `

  -Server 172.16.66.53 `

  -DnsOnly

# Содержательная проверка DNS по TCP.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 172.16.66.53 `

  -DnsOnly `

  -TcpOnly

# Проверка установки TCP-соединения на порт 53.

Test-NetConnection `

  -ComputerName 172.16.66.53 `

  -Port 53 `

  -InformationLevel Detailed

18.2.3. Розлив — 172.16.68.0/23, VLAN 2002

# Прямая запись: имя DNS-сервера должно вернуть RRset из пяти A-адресов.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 172.16.68.53 `

  -DnsOnly

# Обратная запись: локальный DNS-адрес должен вернуть имя сервера.

Resolve-DnsName `

  -Name 172.16.68.53 `

  -Type PTR `

  -Server 172.16.68.53 `

  -DnsOnly

# Содержательная проверка DNS по TCP.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 172.16.68.53 `

  -DnsOnly `

  -TcpOnly

# Проверка установки TCP-соединения на порт 53.

Test-NetConnection `

  -ComputerName 172.16.68.53 `

  -Port 53 `

  -InformationLevel Detailed

18.2.4. Утилиты — 172.16.70.0/23, VLAN 2040

# Прямая запись: имя DNS-сервера должно вернуть RRset из пяти A-адресов.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 172.16.70.53 `

  -DnsOnly

# Обратная запись: локальный DNS-адрес должен вернуть имя сервера.

Resolve-DnsName `

  -Name 172.16.70.53 `

  -Type PTR `

  -Server 172.16.70.53 `

  -DnsOnly

# Содержательная проверка DNS по TCP.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 172.16.70.53 `

  -DnsOnly `

  -TcpOnly

# Проверка установки TCP-соединения на порт 53.

Test-NetConnection `

  -ComputerName 172.16.70.53 `

  -Port 53 `

  -InformationLevel Detailed

18.2.5. АСТУЭ — 172.17.14.0/24, VLAN 2006

# Прямая запись: имя DNS-сервера должно вернуть RRset из пяти A-адресов.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 172.17.14.53 `

  -DnsOnly

# Обратная запись: локальный DNS-адрес должен вернуть имя сервера.

Resolve-DnsName `

  -Name 172.17.14.53 `

  -Type PTR `

  -Server 172.17.14.53 `

  -DnsOnly

# Содержательная проверка DNS по TCP.

Resolve-DnsName `

  -Name smr-srv-ot-dns.ot-samara.baltika.ru `

  -Type A `

  -Server 172.17.14.53 `

  -DnsOnly `

  -TcpOnly

# Проверка установки TCP-соединения на порт 53.

Test-NetConnection `

  -ComputerName 172.17.14.53 `

  -Port 53 `

  -InformationLevel Detailed

В A-ответе порядок адресов может изменяться — DNS RRset не задаёт приоритет. Корректный набор: 10.255.0.53, 172.16.66.53, 172.16.68.53, 172.16.70.53, 172.17.14.53.

18.3. Диагностика AmneziaVPN и локального DNS

Первоначально клиент 10.255.255.250 успешно выполнял ping 10.255.0.53, но запросы Resolve-DnsName, nslookup и TCP/53 завершались тайм-аутом.

Маршрут Windows был правильным:

10.255.0.53

→ 10.255.0.0/16

→ Ethernet

→ source 10.255.255.250

→ NextHop 0.0.0.0

Первый захват на Ubuntu показывал ICMP, но не показывал ни UDP/53, ни TCP/53:

sudo tcpdump -ni any -vv   'host 10.255.255.250 and (icmp or udp port 53 or tcp port 53)'

Следовательно, DNS-пакеты блокировались на Windows до выхода через Ethernet. Причиной оказался AmneziaVPN и его защита локального DNS/DNS leak через Windows Filtering Platform.

После отключения VPN в tcpdump появились:

UDP-запросы и ответы для A и PTR;

TCP SYN, SYN-ACK и ACK;

полноценный DNS-запрос и авторитетный ответ по TCP.

Для постоянной совместной работы VPN и OT-DNS в клиенте VPN требуется исключить сеть 10.255.0.0/16 и разрешить обращения к 10.255.0.53 по UDP/53 и TCP/53 либо включить доступ к локальной сети и локальному DNS.

Не смешивать две разные неисправности: в раннем тесте AmneziaVPN действительно блокировал локальный DNS до выхода пакетов с Windows. В отдельном тесте reverse-DDNS для 172.16.71.250 VPN уже был отключён; причиной отсутствия PTR был многозначный SOA MNAME reverse-зоны. После назначения локального MNAME с единственной A-записью Windows отправила UPDATE.

18.4. Ожидаемый REFUSED для внешних имён

После назначения OT-DNS системным DNS Windows отправляет на него фоновые запросы приложений и операционной системы, например client.wns.windows.com, yandex.ru, chatgpt.com и корпоративные зоны.

BIND отвечает на них REFUSED, поскольку работает в авторитетном режиме:

recursion no;

allow-query-cache { none; };

Это штатное поведение. Если OT-клиентам требуется разрешение корпоративных или внешних зон, нужно отдельно проектировать условную пересылку или доверенный forwarder. Второй DNS-сервер в настройках Windows не гарантирует разделение запросов по зонам.

18.5. Сообщения bad udp cksum в tcpdump

Строки bad udp cksum или cksum incorrect для исходящих пакетов сервера обычно являются следствием checksum offloading: tcpdump видит пакет до вычисления окончательной контрольной суммы виртуальным или физическим адаптером. При успешном ответе клиента и завершённом TCP-обмене это не является сетевой ошибкой.

19. Важный нюанс нескольких A-записей DNS-сервера

Имя smr-srv-ot-dns.ot-samara.baltika.ru имеет пять A-записей — по одному сервисному адресу в каждой OT-сети. Для обычных запросов это допустимо, но для поля MNAME reverse-зоны оказалось неприемлемо: Windows получает primary из SOA, разрешает его имя и может выбрать недоступный адрес другой сети.

Подтверждённая неисправность на адресе 172.16.71.250/23 выглядела так:

UPDATE прямой зоны → успешно

SOA? 250.71.16.172.in-addr.arpa → reverse-зона найдена

A? smr-srv-ot-dns.ot-samara.baltika.ru → получено пять IP

UPDATE зоны 71.16.172.in-addr.arpa → на локальный DNS не отправлен

Решение реализовано для всех reverse-зон: SOA MNAME и NS указывают на локальное имя ns-*, имеющее ровно одну A-запись.

Сети	Имя primary	Адрес
10.255.0.0/16	ns-10-255.ot-samara.baltika.ru.	10.255.0.53
172.16.66.0/23	ns-172-16-66.ot-samara.baltika.ru.	172.16.66.53
172.16.68.0/23	ns-172-16-68.ot-samara.baltika.ru.	172.16.68.53
172.16.70.0/23	ns-172-16-70.ot-samara.baltika.ru.	172.16.70.53
172.17.14.0/24	ns-172-17-14.ot-samara.baltika.ru.	172.17.14.53

После изменения Windows выполнила полную цепочку SOA → A primary → UPDATE PTR, а BIND добавил 250.71.16.172.in-addr.arpa PTR SMROTNBK01.ot-samara.baltika.ru.. Аналогично подтверждена зона 69.16.172.in-addr.arpa для адреса 172.16.69.250.

# Каждое служебное имя должно вернуть один адрес.

for host in   ns-10-255   ns-172-16-66   ns-172-16-68   ns-172-16-70   ns-172-17-14

do

  echo "===== $host ====="

  dig @127.0.0.1 "$host.ot-samara.baltika.ru" A +norecurse +short

done

Прямая зона по-прежнему использует многозначное имя smr-srv-ot-dns. В пилотах A-обновления проходили успешно из всех сетей, поэтому её MNAME не изменялся. Это остаётся отдельным архитектурным ограничением и должно учитываться при дальнейшем усилении DDNS.

20. Установка и проверка Webmin

20.1. Назначение и границы использования

Webmin установлен как веб-интерфейс для администрирования работающего BIND9. Он читает существующие /etc/bind/named.conf* и файлы зон в /var/lib/bind/zones.

Все рабочие зоны сейчас динамические. Webmin используется для ручных A/PTR/CNAME/TXT-записей по подтверждённой схеме Freeze → Edit → Thaw. Для отображения свежих DDNS-записей из .jnl перед просмотром выполняется пользовательская команда Синхронизировать DDNS-зоны.

20.2. Контрольная копия перед установкой

# Формируем имя каталога с датой и временем.

backup_dir="/root/bind9-before-webmin-$(date +%F-%H%M%S)"

# install -d создаёт каталог; -m 0700 оставляет доступ только root.

install -d -m 0700 "$backup_dir"

# cp -a копирует рекурсивно и сохраняет владельцев, права и временные метки.

cp -a \

  /etc/bind \

  /var/lib/bind/zones \

  /etc/netplan \

  /etc/ufw \

  "$backup_dir/"

# -C /root меняет рабочий каталог tar перед упаковкой.

# -c создаёт архив, -z включает gzip, -f задаёт имя файла.

tar -C /root -czf "${backup_dir}.tar.gz" "$(basename "$backup_dir")"

# Создаём и сразу проверяем контрольную сумму архива.

sha256sum "${backup_dir}.tar.gz" | tee "${backup_dir}.tar.gz.sha256"

sha256sum -c "${backup_dir}.tar.gz.sha256"

Фактическая резервная точка:

/root/bind9-before-webmin-2026-07-28-152931.tar.gz

SHA-256: 5e0db79047d44a7fca97c910c6d6656e250a90a6d0711065712acbf1c64897bd

Дополнительно были сохранены хеши 21 файла BIND. Пустой вывод последующего diff подтвердил, что сама установка Webmin не изменила конфигурацию DNS.

# find выбирает обычные файлы в двух каталогах.

# -exec sha256sum {} + передаёт их sha256sum группами.

# sort -k2 сортирует по второму полю — пути к файлу.

find /etc/bind /var/lib/bind/zones \

  -type f \

  -exec sha256sum {} + | \

sort -k2 > /root/bind-before-webmin.sha256

20.3. Доступ через UFW

Webmin доступен только через management-интерфейсы. На OT-интерфейсах TCP/10000 не разрешён.

# Временный management-доступ на период миграции.

ufw allow in on ens18   proto tcp   from 192.168.1.0/24   to 192.168.1.53   port 10000   comment 'Webmin temporary management HTTPS'

# Production management: 10.44.3.65/21 принадлежит сети 10.44.0.0/21.

ufw allow in on ens23   proto tcp   from 10.44.0.0/21   to 10.44.100.228   port 10000   comment 'Webmin management 10.44.0.0/21'

ufw reload

ufw status numbered

Фактически проверено подключение к https://10.44.100.228:10000 с адреса 10.44.3.65. Если TCP/10000 разрешён UFW, но Webmin всё равно отклоняет клиента, дополнительно проверяется Webmin → Webmin Configuration → IP Access Control: при включённом allow-list туда добавляется 10.44.0.0/21.

20.4. Подключение официального stable-репозитория

cd /root

# --fail завершает curl ошибкой при HTTP 4xx/5xx.

# --location разрешает HTTPS-перенаправления.

# --proto '=https' запрещает загрузку по HTTP.

# --tlsv1.2 требует TLS 1.2 или новее.

curl \

  --fail \

  --location \

  --proto '=https' \

  --tlsv1.2 \

  --output /root/webmin-setup-repo.sh \

  https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh

file /root/webmin-setup-repo.sh

head -n 20 /root/webmin-setup-repo.sh

sha256sum /root/webmin-setup-repo.sh

chmod 0700 /root/webmin-setup-repo.sh

# Скрипт добавляет stable-репозиторий и ключ подписи Webmin.

sh /root/webmin-setup-repo.sh

apt-get update

apt-cache policy webmin

Перед установкой был обнаружен пакет webmin 2.653 из репозитория https://download.webmin.com/download/newkey/repository.

20.5. Установка и проверка службы

# --install-recommends устанавливает рекомендуемые зависимости Webmin.

apt-get install webmin --install-recommends

# is-active проверяет текущее состояние процесса.

systemctl is-active webmin

# is-enabled проверяет запуск при загрузке ОС.

systemctl is-enabled webmin

# Показываем слушающий сокет TCP/10000 и процесс-владелец.

ss -lntp | grep ':10000'

# --insecure разрешён только для первичной проверки локального self-signed сертификата.

curl --insecure --head https://127.0.0.1:10000/

Подтверждённое состояние:

Webmin: 2.653

webmin.service: active, enabled

TCP/10000: LISTEN на 0.0.0.0 и [::]

HTTPS: HTTP/1.0 200 Document follows

Хотя процесс слушает все локальные адреса, входящий IPv4-доступ ограничен правилами UFW только management-сетями.

20.6. Проверка неизменности BIND после установки

find /etc/bind /var/lib/bind/zones   -type f   -exec sha256sum {} + |

sort -k2 > /root/bind-after-webmin.sha256

diff -u   /root/bind-before-webmin.sha256   /root/bind-after-webmin.sha256

named-checkconf -z

systemctl is-active named

На момент установки Webmin проверка хешей подтвердила, что веб-интерфейс не изменил исходную статическую конфигурацию. Затем отдельным контролируемым этапом DDNS был включён и allow-update заменён на ACL сетей, приведённые в разделе 14.5.

# Текущая эффективная конфигурация зон и ACL.

named-checkconf -p |

grep -A 12 -E '^zone "(ot-samara|255\.10|6[6-9]\.16\.172|7[01]\.16\.172|14\.17\.172)'

# Все зоны должны загрузиться.

named-checkconf -z

20.7. Первое открытие модуля BIND

Адреса интерфейса:

https://192.168.1.53:10000

https://10.44.100.228:10000

Вход выполняется под Linux-пользователем baltikadns. В меню Серверы → Сервер DNS BIND Webmin автоматически определил BIND 9.18.39, прямую зону, восемь обратных зон и стандартные локальные зоны. Создавать новую конфигурацию BIND не потребовалось.

Когда существующая конфигурация не обнаружена, нельзя нажимать Create Configuration: сначала проверяются пути модуля. В этой установке существующие зоны обнаружены корректно.

Если модуль не обнаружил существующие зоны, не нажимать Create Configuration. В Module Config должны использоваться проектные пути:

Main configuration file: /etc/bind/named.conf

Options file:            /etc/bind/named.conf.options

Local zones file:        /etc/bind/named.conf.local

Zone files directory:    /var/lib/bind/zones

named-checkconf:          /usr/sbin/named-checkconf

named-checkzone:          /usr/sbin/named-checkzone

rndc:                     /usr/sbin/rndc

systemd service:          named.service

Chroot:                   не используется

20.8. Функциональный тест редактирования зоны

После включения DDNS выполнен отдельный тест изменения динамической зоны через Webmin. В прямой зоне была создана и удалена временная TXT-запись, при этом существующие динамические A/PTR клиента сохранились.

выполнить Синхронизировать DDNS-зоны;

создать временную TXT-запись webmin-dynamic-test;

сохранить изменение через Webmin;

проверить dynamic: yes и frozen: no;

проверить TXT и существующие DDNS-записи через dig;

удалить тестовую запись и повторить проверку.

named-checkconf -z

rndc zonestatus ot-samara.baltika.ru |

grep -E '^(name|serial|dynamic|frozen):'

dig @127.0.0.1   webmin-dynamic-test.ot-samara.baltika.ru   TXT   +norecurse   +noall   +comments   +answer

dig @127.0.0.1   SMROTNBK01.ot-samara.baltika.ru   A   +norecurse   +short

Полный цикл проверен успешно. Webmin увеличил serial, разморозил зону и не потерял клиентские записи из DDNS.

20.9. Официальные справочные материалы

Установка Webmin и настройка репозитория;

Модуль Webmin BIND DNS Server;

Исходный код скрипта настройки репозитория.

20.10. Пользовательские команды Webmin

Название в Webmin	Команда	Назначение
Синхронизировать DDNS-зоны	/usr/local/sbin/bind-sync-ddns-zones	Выполняет rndc sync для прямой и восьми reverse-зон.
1. Текущие несовпадения PTR/A	/usr/local/sbin/bind-ptr-mismatch report	Формирует отчёт о PTR, которые противоречат текущей A-записи.
2. Убрать текущие несовпадения PTR/A	/usr/local/sbin/bind-ptr-mismatch clean	Удаляет только строго подтверждённые устаревшие PTR.

Команды добавлены в Прочие → Пользовательские команды и проверены фактическим выполнением.

21. Правила редактирования зон

Все девять рабочих зон динамические. Их нельзя редактировать напрямую во время работы named, потому что актуальные изменения могут находиться в журнале .jnl и быть перезаписаны при следующей синхронизации.

21.1. Предпочтительный способ через Webmin

открыть нужную зону в Серверы → Сервер DNS BIND;

создать, изменить или удалить запись;

сохранить изменение;

убедиться, что зона снова имеет frozen: no;

выполнить пользовательскую команду Синхронизировать DDNS-зоны;

проверить запись через dig.

На сервере подтверждено, что Webmin выполняет защитный цикл freeze → изменение файла и serial → thaw, а существующие DDNS-записи при этом сохраняются.

21.2. Ручной CLI-цикл

# Замораживаем и синхронизируем live-журнал с файлом.

sudo rndc freeze ot-samara.baltika.ru

# Редактируем файл и увеличиваем serial.

sudo nano /var/lib/bind/zones/db.ot-samara.baltika.ru

# Проверяем файл до возврата DDNS.

sudo named-checkzone   ot-samara.baltika.ru   /var/lib/bind/zones/db.ot-samara.baltika.ru

# Перечитываем файл и возвращаем динамические обновления.

sudo rndc thaw ot-samara.baltika.ru

# Контроль состояния.

sudo rndc zonestatus ot-samara.baltika.ru |

  grep -E '^(name|serial|dynamic|frozen):'

Целевой результат:

dynamic: yes

frozen: no

21.3. Синхронизация без остановки DDNS

sudo rndc sync ot-samara.baltika.ru

sudo rndc sync 69.16.172.in-addr.arpa

rndc sync переносит текущее состояние из .jnl в основной файл зоны, но не замораживает зону и не отключает DDNS.

21.4. Резервное копирование динамических зон

backup="/root/bind9-dynamic-backup-$(date +%F-%H%M%S)"

sudo install -d -m 0700 "$backup"

# Сначала синхронизируем зоны.

sudo /usr/local/sbin/bind-sync-ddns-zones

# Копируем конфигурацию, основные файлы и сохранившиеся .jnl.

sudo cp -a /etc/bind "$backup/"

sudo cp -a /var/lib/bind/zones "$backup/"

sudo tar -C /root -czf "${backup}.tar.gz" "$(basename "$backup")"

sudo sha256sum "${backup}.tar.gz" |

  sudo tee "${backup}.tar.gz.sha256"

sudo sha256sum -c "${backup}.tar.gz.sha256"

22. DDNS для статических Windows-клиентов

22.1. Параметры OT-интерфейса

Сеть клиента	DNS	Маска	Шлюз на OT-интерфейсе
10.255.0.0/16	10.255.0.53	255.255.0.0	не задаётся
172.16.66.0/23	172.16.66.53	255.255.254.0	не задаётся
172.16.68.0/23	172.16.68.53	255.255.254.0	не задаётся
172.16.70.0/23	172.16.70.53	255.255.254.0	не задаётся
172.17.14.0/24	172.17.14.53	255.255.255.0	не задаётся

Для OT-интерфейса задаётся DNS-суффикс ot-samara.baltika.ru и включается регистрация адреса этого подключения в DNS. На Wi-Fi, VPN и других не-OT интерфейсах автоматическая регистрация отключается.

# Просмотр состояния регистрации интерфейсов.

Get-DnsClient |

  Format-Table InterfaceAlias,InterfaceIndex,ConnectionSpecificSuffix,RegisterThisConnectionsAddress

# Пример отключения регистрации на конкретном VPN-интерфейсе.

Set-DnsClient `

  -InterfaceIndex <индекс_VPN> `

  -RegisterThisConnectionsAddress $false

22.2. Ручной запуск регистрации

ipconfig /flushdns

ipconfig /registerdns

ipconfig /registerdns запускает асинхронную регистрацию всех подходящих адаптеров. Сообщение «Начата регистрация» означает, что задание передано службе DNS Client, а не что A и PTR уже созданы.

A и PTR являются отдельными обновлениями:

FQDN → SOA прямой зоны → UPDATE A

IP   → SOA reverse-зоны → A primary из MNAME → UPDATE PTR

22.3. Наблюдение на сервере

# Журнал BIND.

journalctl -u named -f |

grep --line-buffered -E \

'updating zone|update denied|ot-samara\.baltika\.ru|in-addr\.arpa'

# Трафик конкретного клиента; интерфейс меняется по сети.

tcpdump -ni ens22 \

  'host 172.16.71.250 and port 53'

Успешная reverse-регистрация включает запрос SOA обратного имени, запрос A локального ns-* и пакет с opcode UPDATE.

22.4. Проверка A и PTR

dig @127.0.0.1 \

  SMROTNBK01.ot-samara.baltika.ru \

  A \

  +norecurse \

  +short

dig @127.0.0.1 \

  -x 172.16.69.250 \

  +norecurse \

  +short

Целевой результат — взаимно согласованная пара:

SMROTNBK01.ot-samara.baltika.ru → 172.16.69.250

172.16.69.250 → SMROTNBK01.ot-samara.baltika.ru.

22.5. Подтверждённые пилоты

Сеть	Фактический тестовый адрес	Результат
172.17.14.0/24	172.17.14.200	A и PTR зарегистрированы
10.255.0.0/16	10.255.255.250	A и PTR зарегистрированы
172.16.66.0/23	172.16.66.89	A и PTR зарегистрированы; адрес .250 был занят
172.16.68.0/23	172.16.69.250	A и PTR зарегистрированы в зоне 69.16.172.in-addr.arpa
172.16.70.0/23	172.16.71.250	A и PTR зарегистрированы в зоне 71.16.172.in-addr.arpa

22.6. DNS suffix search list для коротких имён

Основной connection-specific DNS suffix обычного Windows-компьютера остаётся ot-samara.baltika.ru. Поэтому его собственная DDNS-регистрация продолжает создавать HOST.ot-samara.baltika.ru.

Для разрешения коротких имён многосетевых сервисов задаётся отдельный DNS suffix search list из двух элементов: первым локальный сегментный suffix, вторым общая OT-зона.

Сегмент клиента	Первый suffix	Второй suffix
Legacy	legacy.ot-samara.baltika.ru	ot-samara.baltika.ru
Пивопроизводство	pivo.ot-samara.baltika.ru	ot-samara.baltika.ru
Розлив	rozliv.ot-samara.baltika.ru	ot-samara.baltika.ru
Утилиты	utilities.ot-samara.baltika.ru	ot-samara.baltika.ru
АСТУЭ	astue.ot-samara.baltika.ru	ot-samara.baltika.ru

Пример для клиента Розлива:

Set-DnsClientGlobalSetting `
  -SuffixSearchList @(
    "rozliv.ot-samara.baltika.ru",
    "ot-samara.baltika.ru"
  )

Get-DnsClientGlobalSetting
ipconfig /flushdns

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

22.7. Split DNS для многосетевых Linux-серверов

На многосетевом Linux-сервере локальный DNS каждого OT-сегмента назначается соответствующему интерфейсу через Netplan. Поскольку OT BIND является авторитетным и не выполняет рекурсию, используются route-only domains systemd-resolved с префиксом ~. Они определяют, куда направлять запрос к конкретной зоне, но не являются search suffix для короткого имени.

Проверенная схема SMR-SRV-OT-SHARE:

Интерфейс SHARE	Адрес SHARE	DNS	Назначение
ens23	10.255.0.229/16	10.255.0.53	Legacy
ens23, временно	172.16.66.229/23	172.16.66.53	Пивопроизводство до VLAN2030
ens20	172.16.68.229/23	172.16.68.53	Розлив
ens22	172.16.70.229/23	172.16.70.53	Утилиты
enp2s1	172.17.14.229/24	172.17.14.53	АСТУЭ

Пример блока Netplan для Розлива:

ens20:
  addresses:
    - 172.16.68.229/23
  nameservers:
    addresses:
      - 172.16.68.53
    search:
      - "~ot-samara.baltika.ru"
      - "~68.16.172.in-addr.arpa"
      - "~69.16.172.in-addr.arpa"

Для ens23 одновременно используются DNS 10.255.0.53 и 172.16.66.53 и route-only зоны ~ot-samara.baltika.ru, ~255.10.in-addr.arpa, ~66.16.172.in-addr.arpa и ~67.16.172.in-addr.arpa. Для Утилит используются ~70.16.172.in-addr.arpa и ~71.16.172.in-addr.arpa. Для АСТУЭ — ~14.17.172.in-addr.arpa.

Management-интерфейс SMR-SRV-OT-SHARE не использует 10.44.100.228 как DNS: BIND на management-IP DNS-ВМ намеренно не слушает TCP/UDP 53.

Применение:

sudo netplan generate
sudo netplan try --timeout 120
resolvectl status

На SMR-SRV-OT-SHARE подтверждено: 172.16.68.53 маршрутизируется через ens20, 172.16.70.53 через ens22, 10.255.0.53 и 172.16.66.53 через ens23, 172.17.14.53 через enp2s1. Прямая зона ot-samara.baltika.ru также разрешается через OT DNS. Внешнее имя archive.ubuntu.com в текущей переходной конфигурации файлового сервера разрешялось через ens18 и 192.168.1.1, то есть авторитетный OT BIND не стал глобальным recursive resolver.

22.8. DDNS многосетевого Linux-сервера через nsupdate

systemd-resolved выполняет разрешение имён, но не регистрирует статические Linux-адреса в BIND через RFC 2136. Для многосетевого Linux-сервера используется отдельный контролируемый скрипт.

Проверенная схема SMR-SRV-OT-SHARE:

Сегмент	IP	FQDN
Legacy	10.255.0.229	smr-srv-ot-share.legacy.ot-samara.baltika.ru
Пивопроизводство	172.16.66.229	smr-srv-ot-share.pivo.ot-samara.baltika.ru
Розлив	172.16.68.229	smr-srv-ot-share.rozliv.ot-samara.baltika.ru
Утилиты	172.16.70.229	smr-srv-ot-share.utilities.ot-samara.baltika.ru
АСТУЭ	172.17.14.229	smr-srv-ot-share.astue.ot-samara.baltika.ru

22.8.1. Скрипт /usr/local/sbin/ot-ddns-register

#!/usr/bin/env bash

# Регистрация интерфейсных имён многосетевого Linux-сервера
# в BIND9 через RFC 2136 / nsupdate.

set -euo pipefail

TTL=3600
ZONE="ot-samara.baltika.ru."

register_dns()
{
    local iface="$1"
    local ip="$2"
    local dns="$3"
    local fqdn="$4"
    local ptr="$5"

    echo
    echo "============================================================"
    echo "Interface : $iface"
    echo "IP        : $ip"
    echo "DNS       : $dns"
    echo "FQDN      : $fqdn"
    echo "============================================================"

    if ! ip -4 addr show dev "$iface" | grep -qw "$ip"; then
        echo "ERROR: IP $ip отсутствует на интерфейсе $iface"
        return 1
    fi

    route_info="$(ip route get "$dns" | head -n1)"
    echo "Route     : $route_info"

    if ! grep -qw "src $ip" <<< "$route_info"; then
        echo "ERROR: запрос к $dns пойдёт не с source IP $ip"
        return 1
    fi

    nsupdate <<EOF
server $dns
zone $ZONE
update delete $fqdn A
update add $fqdn $TTL A $ip
send
EOF

    nsupdate <<EOF
server $dns
update delete $ptr PTR
update add $ptr $TTL PTR $fqdn
send
EOF

    result_a="$(dig +short +norecurse @"$dns" "$fqdn" A | head -n1)"
    [[ "$result_a" == "$ip" ]] || {
        echo "ERROR: A verification failed: '$result_a'"
        return 1
    }

    result_ptr="$(dig +short +norecurse @"$dns" -x "$ip" | head -n1)"
    [[ "$result_ptr" == "$fqdn" ]] || {
        echo "ERROR: PTR verification failed: '$result_ptr'"
        return 1
    }

    echo "OK: A   $fqdn -> $ip"
    echo "OK: PTR $ip -> $fqdn"
}

register_dns "ens23" "10.255.0.229" "10.255.0.53" \
  "smr-srv-ot-share.legacy.ot-samara.baltika.ru." \
  "229.0.255.10.in-addr.arpa."

# После миграции VLAN2030 заменить ens23 на ens21.
register_dns "ens23" "172.16.66.229" "172.16.66.53" \
  "smr-srv-ot-share.pivo.ot-samara.baltika.ru." \
  "229.66.16.172.in-addr.arpa."

register_dns "ens20" "172.16.68.229" "172.16.68.53" \
  "smr-srv-ot-share.rozliv.ot-samara.baltika.ru." \
  "229.68.16.172.in-addr.arpa."

register_dns "ens22" "172.16.70.229" "172.16.70.53" \
  "smr-srv-ot-share.utilities.ot-samara.baltika.ru." \
  "229.70.16.172.in-addr.arpa."

register_dns "enp2s1" "172.17.14.229" "172.17.14.53" \
  "smr-srv-ot-share.astue.ot-samara.baltika.ru." \
  "229.14.17.172.in-addr.arpa."

echo
echo "============================================================"
echo "OT DDNS registration completed successfully."
echo "============================================================"

Права:

sudo chown root:root /usr/local/sbin/ot-ddns-register
sudo chmod 0755 /usr/local/sbin/ot-ddns-register

22.8.2. Автоматическая регистрация через systemd

# /etc/systemd/system/ot-ddns-register.service

[Unit]
Description=Register SMR-SRV-OT-SHARE DNS records in OT BIND9
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/ot-ddns-register

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable ot-ddns-register.service
sudo systemctl start ot-ddns-register.service
sudo systemctl status ot-ddns-register.service --no-pager
sudo journalctl -u ot-ddns-register.service -n 100 --no-pager

Для Type=oneshot состояние inactive (dead) после завершения является нормальным. Критерий успеха: code=exited, status=0/SUCCESS и строки OK: A / OK: PTR по всем интерфейсам.

На SMR-SRV-OT-SHARE 05.11.2026 ручной запуск скрипта и запуск через systemd успешно зарегистрировали и проверили все пять пар A/PTR.

23. Синхронизация DDNS-зон и отображение в Webmin

Работающий BIND может уже отвечать новой записью из .jnl, а Webmin ещё показывать старое содержимое основного файла. Перед просмотром зон выполняется синхронизация.

23.1. Скрипт синхронизации

sudo tee /usr/local/sbin/bind-sync-ddns-zones >/dev/null <<'EOF'

#!/usr/bin/env bash

set -Eeuo pipefail

zones=(

  ot-samara.baltika.ru

  255.10.in-addr.arpa

  66.16.172.in-addr.arpa

  67.16.172.in-addr.arpa

  68.16.172.in-addr.arpa

  69.16.172.in-addr.arpa

  70.16.172.in-addr.arpa

  71.16.172.in-addr.arpa

  14.17.172.in-addr.arpa

)

for zone in "${zones[@]}"; do

  printf 'sync: %s\n' "$zone"

  rndc sync "$zone"

done

EOF

sudo chown root:root /usr/local/sbin/bind-sync-ddns-zones

sudo chmod 0750 /usr/local/sbin/bind-sync-ddns-zones

23.2. Порядок просмотра

запустить в Webmin Синхронизировать DDNS-зоны;

закрыть и снова открыть страницу зоны;

при необходимости выполнить обновление браузера Ctrl+F5;

сверить запись с live-ответом dig.

/usr/local/sbin/bind-sync-ddns-zones

named-checkconf -z

find /var/lib/bind/zones \

  -maxdepth 1 \

  -type f \

  -name '*.jnl' \

  -ls

Наличие .jnl является нормальным признаком динамической зоны. Синхронизация не требует удалять журнал и не отключает DDNS.

Важно для Windows и Linux DDNS: после успешного UPDATE запись уже существует в live-состоянии BIND и доступна через dig. rndc sync и /usr/local/sbin/bind-sync-ddns-zones не создают запись заново, а только переносят текущее live-состояние из .jnl в основной файл зоны, чтобы изменение было видно при просмотре файла и в Webmin.

24. Контроль и очистка старых PTR

При переносе статического Windows-хоста в другую подсеть клиент регистрирует новый A и новый PTR, но старый PTR в прежней reverse-зоне может сохраниться. Периодическая повторная регистрация Windows не является scavenging и не гарантирует удаление записи из другой зоны.

24.1. Утилита контроля

/usr/local/sbin/bind-ptr-mismatch report

/usr/local/sbin/bind-ptr-mismatch clean

На сервере установлена и проверена версия 2.0.0. Последний отчёт сохраняется в:

/var/lib/bind/ptr-mismatch/latest.tsv

sed -n '1,40p' \

  /var/lib/bind/ptr-mismatch/latest.tsv

24.2. Правила безопасной очистки

автоматически удаляется только строгий mismatch: PTR указывает на имя, а текущий A этого имени содержит другой IP;

PTR для имени без A-записи отображается в отчёте, но автоматически не удаляется;

обычная очистка ограничена максимум 20 удалениями за запуск;

принудительное превышение лимита допускается только из консоли с осознанным параметром --force-many;

после очистки зоны синхронизируются и повторно проверяются через dig.

24.3. Кнопки Webmin

Прочие

→ Пользовательские команды

→ 1. Текущие несовпадения PTR/A

→ 2. Убрать текущие несовпадения PTR/A

Обе команды проверены на фактическом переносе пилотного ноутбука между OT-сетями.

25. Эксплуатация: как правильно пользоваться DNS, DDNS и Webmin

Этот раздел является рабочей инструкцией для повседневной эксплуатации. Основной принцип: Windows-компьютеры регистрируют A/PTR через DDNS, оборудование без DDNS сопровождается вручную через Webmin, а фактическое состояние всегда подтверждается запросом к работающему BIND.

Источник истины: ответ dig или Resolve-DnsName от локального сервисного адреса DNS показывает состояние работающего named. Webmin показывает содержимое основного файла зоны и после DDNS может требовать предварительной синхронизации .jnl.

25.1. Что для чего использовать

Задача	Правильный инструмент	Комментарий
Регистрация статического Windows-компьютера	Настройки сетевого интерфейса Windows и ipconfig /registerdns	Клиент самостоятельно создаёт или обновляет A и PTR.
Добавление ПЛК, HMI, счётчика, коммутатора или другого устройства без DDNS	Webmin → BIND DNS Server	A и PTR создаются вручную как согласованная пара.
Проверка фактического ответа DNS	dig или Resolve-DnsName	Проверяется работающий BIND, а не только отображение Webmin.
Показать в Webmin последние DDNS-записи	Пользовательская команда Синхронизировать DDNS-зоны	Выгружает изменения из journal в основной файл зоны.
Найти старые PTR после смены адреса	1. Текущие несовпадения PTR/A	Сначала только отчёт, без удаления.
Удалить подтверждённые старые PTR	2. Убрать текущие несовпадения PTR/A	Запускается только после просмотра отчёта.
Массовое или аварийное изменение файлов зон	CLI с rndc freeze/thaw	Не выполнять обычному оператору без резервной копии и проверки.

25.2. Какой DNS-адрес назначать клиенту

Сеть клиента	Маска	DNS-сервер	Обратная зона
10.255.0.0/16	255.255.0.0	10.255.0.53	255.10.in-addr.arpa
172.16.66.0/23	255.255.254.0	172.16.66.53	66 или 67.16.172.in-addr.arpa
172.16.68.0/23	255.255.254.0	172.16.68.53	68 или 69.16.172.in-addr.arpa
172.16.70.0/23	255.255.254.0	172.16.70.53	70 или 71.16.172.in-addr.arpa
172.17.14.0/24	255.255.255.0	172.17.14.53	14.17.172.in-addr.arpa

На OT-интерфейсе задаётся только локальный DNS своей сети.

DNS-адрес другой OT-подсети не используется: между сегментами нет гарантированной маршрутизации.

На OT-интерфейсе шлюз не задаётся, если он не требуется отдельным утверждённым проектным решением.

Management-адреса 192.168.1.53 и 10.44.100.228 не являются клиентскими DNS-адресами.

Второй DNS-сервер из другой подсети не обеспечивает корректное разделение запросов и не заменяет локальный адрес.

25.3. Подключение нового Windows-компьютера

Утвердить имя компьютера и свободный статический IP по действующему плану адресации.

На OT-интерфейсе задать IP, правильную маску и локальный DNS из таблицы выше; шлюз оставить пустым.

В дополнительных параметрах IPv4 оставить connection-specific DNS-суффикс ot-samara.baltika.ru. В DNS suffix search list использовать два элемента: первым локальный сегментный суффикс, вторым общую зону ot-samara.baltika.ru. Например, для Розлива: rozliv.ot-samara.baltika.ru, затем ot-samara.baltika.ru.

Включить параметры «Зарегистрировать адреса этого подключения в DNS» и «Использовать DNS-суффикс этого подключения при регистрации».

Отключить регистрацию адресов на Wi-Fi, VPN и других интерфейсах, которые не должны попадать в OT-зону.

Запустить регистрацию и подождать 30–60 секунд.

Проверить A и PTR. Только после этого считать подключение завершённым.

# PowerShell от имени администратора: контроль интерфейсов.

Get-DnsClient |

  Format-Table InterfaceAlias,InterfaceIndex,ConnectionSpecificSuffix,RegisterThisConnectionsAddress -AutoSize

# Ручной запуск регистрации.

ipconfig /flushdns

ipconfig /registerdns

Сообщение Начата регистрация означает только постановку асинхронного задания службе DNS Client. Оно не подтверждает создание обеих записей.

Проверка на DNS-сервере:

# Заменить имя и IP фактическими значениями нового клиента.

dig @127.0.0.1 \

  HOSTNAME.ot-samara.baltika.ru \

  A \

  +norecurse \

  +short

dig @127.0.0.1 \

  -x 172.16.69.250 \

  +norecurse \

  +short

Успешный результат — взаимно согласованная пара:

HOSTNAME.ot-samara.baltika.ru → фактический IP

фактический IP → HOSTNAME.ot-samara.baltika.ru.

25.4. Добавление устройства без DDNS через Webmin

Для ПЛК, HMI, счётчиков, коммутаторов и другого оборудования создаются две записи: A в прямой зоне и PTR в соответствующей обратной зоне.

Проверить, что имя и IP не используются другим объектом.

Открыть Серверы → BIND DNS Server → ot-samara.baltika.ru → Address Records.

Создать A-запись с коротким именем без суффикса, например plc-fill-001, и фактическим IP.

Открыть reverse-зону, соответствующую адресу, и создать PTR на полное имя с точкой в конце: plc-fill-001.ot-samara.baltika.ru.

Запустить Check BIND Configuration, затем применить изменения.

Проверить обе стороны через dig.

Выбор reverse-зоны:

172.16.66.x → 66.16.172.in-addr.arpa

172.16.67.x → 67.16.172.in-addr.arpa

172.16.68.x → 68.16.172.in-addr.arpa

172.16.69.x → 69.16.172.in-addr.arpa

172.16.70.x → 70.16.172.in-addr.arpa

172.16.71.x → 71.16.172.in-addr.arpa

172.17.14.x → 14.17.172.in-addr.arpa

В зоне 255.10.in-addr.arpa используется /16-логика. Например, для 10.255.10.25 владельцем PTR внутри зоны 255.10.in-addr.arpa будет 25.10.

Не создавать только A или только PTR. Рабочей записью считается согласованная пара, если для объекта не утверждено специальное исключение.

25.5. Перенос Windows-компьютера в другую сеть или смена IP

Назначить новый статический IP, маску и локальный DNS новой сети.

Выполнить ipconfig /flushdns и ipconfig /registerdns.

Проверить, что A указывает на новый IP и новый PTR указывает на текущее имя.

В Webmin запустить 1. Текущие несовпадения PTR/A.

Просмотреть отчёт и убедиться, что старый PTR действительно относится к перенесённому хосту.

Запустить 2. Убрать текущие несовпадения PTR/A.

Повторно проверить новый A/PTR и отсутствие старого PTR.

Windows обычно обновляет текущий A и создаёт PTR в новой reverse-зоне, но не обязана удалить PTR из старой зоны. Поэтому отчёт после переноса является обязательным шагом.

25.6. Переименование компьютера

После переименования Windows зарегистрирует новое имя, но старые записи могут сохраниться. Порядок действий:

перезагрузить компьютер после штатного переименования;

выполнить ipconfig /registerdns;

проверить A/PTR нового имени;

через Webmin вручную удалить старую A-запись и связанные CNAME, если они больше не нужны;

запустить отчёт PTR/A и удалить подтверждённый старый PTR;

убедиться, что старое имя больше не разрешается.

Утилита bind-ptr-mismatch контролирует PTR, но не удаляет автоматически старые A-записи или CNAME.

25.7. Вывод узла из эксплуатации

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

Удалить A-запись из прямой зоны.

Удалить PTR из соответствующей reverse-зоны.

Удалить связанные CNAME и другие записи, указывающие на выводимый узел.

Проверить через dig, что старое имя и старый PTR отсутствуют.

Зафиксировать освобождение имени и IP в плане адресации.

25.8. Как правильно смотреть записи в Webmin

Открыть Прочие → Пользовательские команды.

Запустить Синхронизировать DDNS-зоны.

Повторно открыть нужную зону в модуле BIND.

При необходимости выполнить Ctrl+F5.

Сверить запись с dig.

Если dig уже возвращает новую запись, а Webmin её не показывает, это обычно означает, что изменение находится в .jnl, а не ошибку DDNS.

25.9. Безопасное ручное изменение динамической зоны

Обычные точечные изменения выполняются через Webmin. Перед массовой правкой или изменением SOA/NS:

синхронизировать DDNS-зоны;

создать резервную копию /etc/bind и /var/lib/bind/zones;

убедиться, что зона не осталась замороженной после предыдущей операции;

выполнить изменение через Webmin либо контролируемый цикл freeze → edit → check → thaw;

проверить named-checkconf -z и live-ответы;

проверить dynamic: yes и frozen: no.

rndc zonestatus ot-samara.baltika.ru |

  grep -E '^(name|serial|dynamic|frozen):'

named-checkconf -z

systemctl is-active named

Запрещено: редактировать основной файл работающей динамической зоны без freeze, удалять .jnl для «обновления Webmin», уменьшать serial или оставлять зону в состоянии frozen: yes.

25.10. Регулярный эксплуатационный контроль

Периодичность	Действие	Нормальный результат
После каждого добавления или изменения	Проверить A и PTR через dig	Записи взаимно согласованы
После переноса/переименования	Запустить отчёт PTR/A	Нет необъяснимых mismatch
Перед просмотром DDNS-зон в Webmin	Синхронизировать зоны	Интерфейс показывает актуальный файл
Еженедельно	Проверить named, зоны и отчёт PTR/A	active, dynamic: yes, frozen: no
После массовых изменений	Создать и проверить резервную копию	Архив читается, SHA-256 сохранён
После обновления ОС или BIND	Проверить UDP/TCP 53 и ключевые зоны	NOERROR, флаг aa

# Короткая проверка службы и зон.

systemctl is-active named

named-checkconf -z

for zone in \

  ot-samara.baltika.ru \

  255.10.in-addr.arpa \

  66.16.172.in-addr.arpa \

  67.16.172.in-addr.arpa \

  68.16.172.in-addr.arpa \

  69.16.172.in-addr.arpa \

  70.16.172.in-addr.arpa \

  71.16.172.in-addr.arpa \

  14.17.172.in-addr.arpa

do

  rndc zonestatus "$zone" |

    grep -E '^(name|serial|dynamic|frozen):'

done

25.11. Быстрая диагностика типовых ситуаций

Симптом	Что это обычно означает	Следующее действие
A и PTR есть в dig, но не видны в Webmin	Изменения находятся в .jnl	Запустить синхронизацию и повторно открыть страницу зоны
A обновился, PTR отсутствует	Не завершилась отдельная reverse-регистрация	Проверить SOA reverse-зоны, локальный ns-*, журнал и tcpdump
В журнале update denied	IP источника не входит в allow-update нужной зоны	Проверить фактический source IP и ACL; не расширять ACL без анализа
Пакета UPDATE нет на сервере	Windows не сформировала его либо трафик блокируется на клиенте	Проверить DNS Client, регистрацию интерфейса, VPN/WFP и маршрут
Внешние имена получают REFUSED	Авторитетный режим без рекурсии	Считать штатным поведением; не включать рекурсию без отдельного проекта
Остался PTR старого адреса	Windows не выполнила scavenging в прежней зоне	Отчёт PTR/A, затем контролируемая очистка
frozen: yes	Зона осталась замороженной после редактирования	Проверить файл и выполнить rndc thaw <zone>
bad udp cksum в исходящем пакете tcpdump	Checksum offloading	Не считать ошибкой при успешном обмене

25.12. Действия, которые нельзя выполнять

не назначать клиенту DNS-сервер из другой OT-подсети;

не добавлять management-адрес DNS-сервера в настройки OT-клиента;

не включать рекурсию или forwarder только для устранения REFUSED;

не расширять allow-update до any или крупной несогласованной сети;

не удалять .jnl вручную;

не редактировать динамический файл зоны без синхронизации и freeze;

не считать вывод ipconfig /registerdns подтверждением успешного A/PTR;

не запускать очистку PTR без предварительного отчёта;

не создавать новую конфигурацию BIND в Webmin поверх существующей;

не назначать один и тот же сервисный IP одновременно двум интерфейсам при миграции VLAN.

25.13. Минимальные рабочие чек-листы

Операция	Обязательные шаги
Новый Windows-хост	IP/маска/DNS/суффикс → регистрация → A/PTR → синхронизация Webmin
Новое устройство без DDNS	Проверка уникальности → A → PTR → Check Configuration → dig
Смена IP или сети	Новая регистрация → новый A/PTR → отчёт mismatch → очистка старого PTR
Переименование	Регистрация нового имени → удалить старые A/CNAME → очистить старый PTR
Удаление узла	Удалить A/PTR/CNAME → проверить NXDOMAIN/отсутствие PTR → освободить IP в учёте
Ручная правка зоны	Синхронизация → backup → freeze/edit/check/thaw → live-проверка

25.14. Эксплуатация production management

Параметр	Рабочее значение
Адрес сервера	10.44.100.228/24 на ens23
Административная сеть	10.44.0.0/21
Проверенный клиент	10.44.3.65
SSH	TCP/22, разрешён UFW только из management-сетей
Webmin	HTTPS/TCP 10000, разрешён UFW только из management-сетей
Internet/default route	В целевом режиме отсутствуют
Системные DNS Ubuntu	В целевом режиме отсутствуют
NTP	10.44.14.33 и 10.44.14.34 по статическим маршрутам

Минимальная диагностика доступа:

ip -br address show ens23

ip route get 10.44.3.65

ufw status numbered

ss -lntp | grep -E ':(22|10000)'

systemctl is-active ssh webmin

На Windows-клиенте:

Test-NetConnection 10.44.100.228 -Port 22

Test-NetConnection 10.44.100.228 -Port 10000

После удаления default route обновления Ubuntu и Webmin через Интернет становятся недоступны. Обновление выполняется только в отдельное согласованное окно через внутренний репозиторий либо временный контролируемый маршрут.

25.15. Эксплуатация многосетевых сервисов

Для редких многосетевых серверов используется одна базовая hostname и отдельный сегментный FQDN для каждого OT-интерфейса:

HOST.legacy.ot-samara.baltika.ru
HOST.pivo.ot-samara.baltika.ru
HOST.rozliv.ot-samara.baltika.ru
HOST.utilities.ot-samara.baltika.ru
HOST.astue.ot-samara.baltika.ru

PTR каждого IP указывает на FQDN соответствующего интерфейса. Обычные одноинтерфейсные Windows-хосты продолжают использовать HOST.ot-samara.baltika.ru.

25.16. Как работает короткое имя многосетевого сервиса

Короткое имя выбирает локальный интерфейс не на стороне сервера, а за счёт DNS suffix search list клиента. Например, клиент Розлива использует:

rozliv.ot-samara.baltika.ru
ot-samara.baltika.ru

Запрос SMR-SRV-OT-SHARE сначала превращается в SMR-SRV-OT-SHARE.rozliv.ot-samara.baltika.ru и получает 172.16.68.229. Обычный хост, зарегистрированный только в общей зоне, после NXDOMAIN по первому suffix проверяется с ot-samara.baltika.ru.

25.17. Порядок ввода многосетевого Linux-сервера

назначить статические IP на OT-интерфейсах без IP forwarding;

назначить каждому интерфейсу локальный DNS своего сегмента;

добавить route-only domains прямой и соответствующих reverse-зон;

применить Netplan через netplan try;

проверить resolvectl status и маршрутизацию reverse-запросов;

создать сегментные FQDN;

настроить и вручную проверить ot-ddns-register;

включить ot-ddns-register.service;

после первой плановой перезагрузки проверить journal текущего boot.

25.18. Миграция интерфейса многосетевого Linux-сервера

Если сервисный IP остаётся тем же, но переносится на новый VLAN/interface, например 172.16.66.229/23 с ens23 на ens21:

не назначать один IP одновременно двум интерфейсам;

выполнить изменение Netplan атомарно через netplan try;

перенести nameservers и route-only domains на новый интерфейс;

изменить имя интерфейса в /usr/local/sbin/ot-ddns-register;

повторно запустить ot-ddns-register.service и проверить A/PTR.

25.19. Диагностика Linux DDNS и split DNS

Симптом	Причина или проверка	Действие
nsupdate получает update denied	Source IP не входит в allow-update	Проверить ip route get <DNS> и фактический src
A создаётся, PTR нет	Ошибка reverse UPDATE, reverse-зоны или source IP	Проверить SOA reverse-зоны и прямой dig к локальному DNS
FQDN работает, короткое имя нет	Нет нужного suffix или неверен порядок search list	Проверить DNS suffix search list клиента
Короткое имя даёт IP чужого сегмента	Первым стоит чужой suffix либо добавлены suffix всех сегментов	Оставить локальный сегментный suffix и общую OT-зону
ot-ddns-register.service показывает inactive (dead)	Нормально для Type=oneshot после выполнения	Проверить status=0/SUCCESS и journal
A/PTR есть через dig, но не видны в Webmin	Изменение находится в .jnl	Запустить bind-sync-ddns-zones

25.20. Почему BIND Views пока не используются

BIND Views позволяют отдавать разные ответы на одно имя в зависимости от источника запроса, но существенно усложняют структуру зон и сопровождение. Поскольку многосетевых устройств ожидается немного, принято более простое решение: сегментные FQDN внутри существующей зоны плюс двухэлементный DNS suffix search list на клиенте.

Views следует пересмотреть только если многосетевых сервисов станет много или появится обязательное требование иметь один и тот же FQDN с разными ответами для разных сетей.

26. Контроль полноты конфигурационных материалов

В этой редакции собраны фактическая архитектура, полные основные конфигурационные файлы и подтверждённые эксплуатационные процедуры. Конфигурация Proxmox-хоста по-прежнему документируется картой bridge/VLAN/MAC, а не универсальной заменой /etc/network/interfaces.

Файл или объект	Материал
/etc/netplan/01-ot-dns.yaml	Семь интерфейсов, адреса, единственный default route и комментарии VLAN
UFW	SSH/Webmin management и UDP/TCP 53 для каждой OT-сети
/etc/bind/named.conf.options	ACL клиентов, listen-on, авторитетный режим без рекурсии
/etc/bind/named.conf.local	Одна прямая и восемь reverse-зон с действующими DDNS ACL
Файлы зон	Базовые SOA/NS/A/PTR и локальные ns-* для reverse-DDNS
Windows DDNS	Настройки интерфейса, ручная регистрация, журнал, tcpdump и A/PTR-проверки
Webmin	Установка, доступ, работа с динамическими зонами и пользовательские команды
bind-sync-ddns-zones	Полный воспроизводимый скрипт синхронизации девяти зон
bind-ptr-mismatch	Задокументированы версия, интерфейс запуска, формат отчёта и ограничения безопасной очистки
Пилоты	Подтверждены все пять сетей, включая reverse-зоны 69 и 71
Эксплуатационный регламент	Подключение Windows и оборудования без DDNS, перенос, переименование, удаление, диагностика и запрещённые действия
Production management	UFW для 10.44.0.0/21, статический обратный маршрут, SSH/Webmin и диагностика source IP
Изоляция сервера	Целевая Netplan-схема без default route и системных DNS; только маршруты к management и внутреннему NTP

26.1. Дополнение редакции 17

Новый объект	Что зафиксировано
DNS suffix search list	Для одноинтерфейсного клиента: локальный сегментный suffix первым, ot-samara.baltika.ru вторым; основной connection-specific suffix не меняется.
Multi-homed Linux split DNS	Netplan + systemd-resolved route-only domains по каждому OT-интерфейсу.
/usr/local/sbin/ot-ddns-register	RFC 2136-регистрация сегментных A/PTR с проверкой IP, source route и результата dig.
ot-ddns-register.service	systemd oneshot, enabled, проверен успешный запуск.
Модель сегментных имён	legacy, pivo, rozliv, utilities, astue внутри общей зоны ot-samara.baltika.ru.

27. Текущее фактическое состояние

Компонент или проверка	Подтверждённое состояние
Ubuntu Server	24.04.4 LTS, статическая многосетевая конфигурация Netplan применена
Proxmox/QEMU	VirtIO-интерфейсы подключены к нужным bridge/VLAN; qemu-guest-agent активен
Production management	ens23 = 10.44.100.228/24; SSH и Webmin подтверждены с 10.44.3.65 через маршрутизацию
UFW management	TCP/22 и TCP/10000 разрешены на ens23 из сети 10.44.0.0/21; сеть определена из адреса клиента 10.44.3.65/21
Маршрутизация	IP forwarding IPv4/IPv6 отключён. Текущий временный default route удаляется на финальном этапе; целевая схема использует только статические маршруты через 10.44.100.1
Изоляция ОС	Принято решение не предоставлять DNS-ВМ доступ в Интернет и не задавать системные upstream DNS Ubuntu после переноса
UFW DNS	DNS UDP/53 и TCP/53 разрешён только из соответствующих OT-сетей
BIND9	9.18.39; одна прямая и восемь reverse-зон динамические и не заморожены
Режим DNS	Авторитетный сервер без рекурсии и forwarder; внешние имена получают REFUSED
DDNS	Включён во всех девяти рабочих зонах; ACL ограничены проектными сетями
Reverse SOA/NS	Все reverse-зоны используют локальные однозначные имена ns-* с единственной A-записью
Windows-пилоты	A/PTR подтверждены во всех пяти сетях; отдельно проверены 172.16.69.250 и 172.16.71.250
Webmin	2.653; редактирование динамических зон, синхронизация и пользовательские команды проверены
Старые PTR	Отчёт и безопасная очистка через bind-ptr-mismatch 2.0.0 проверены

27.1. Дополнение состояния на 05.11.2026

Компонент или проверка	Подтверждённое состояние
SMR-SRV-OT-SHARE split DNS	Прямая OT-зона и reverse-зоны маршрутизируются через правильные интерфейсы systemd-resolved.
Доступность локальных DNS	10.255.0.53, 172.16.66.53, 172.16.68.53, 172.16.70.53 и 172.17.14.53 возвращают авторитетный SOA.
Linux DDNS	Пять сегментных A/PTR SMR-SRV-OT-SHARE зарегистрированы и проверены.
Автоматизация Linux DDNS	ot-ddns-register.service enabled; systemd-запуск завершён status=0/SUCCESS.
BIND Views	Не используются сознательно; для текущего количества multi-homed сервисов признаны избыточными.

28. Следующие этапы

создать резервную копию Netplan и зафиксировать текущее состояние маршрутов;

добавить постоянный маршрут 10.44.0.0/21 via 10.44.100.1 dev ens23 и точные маршруты к 10.44.14.33/32 и 10.44.14.34/32;

перевести systemd-timesyncd на внутренние NTP-серверы и проверить синхронизацию;

через netplan try удалить default route и системные DNS Ubuntu, подтвердить SSH/Webmin с 10.44.3.65 и отсутствие маршрута в Интернет;

после контрольного периода удалить адрес 192.168.1.53/24, временные UFW-правила на ens18 и при необходимости vNIC net0;

при включённом IP Access Control Webmin добавить 10.44.0.0/21 и удалить временную сеть после миграции;

утвердить промышленную схему именования и продолжить регистрацию рабочих A/PTR;

регулярно запускать отчёт PTR/A и выполнять очистку только после проверки;

усилить аутентификацию UPDATE: оценить TSIG, GSS-TSIG или централизованный DHCP-DDNS;

настроить на firewall проектные шлюзы OT-сетей и матрицу выборочной маршрутизации без SNAT для DNS/DDNS;

выполнить атомарную миграцию 172.16.66.53/23 с enp2s1 на ens21 при вводе VLAN 2030;

спроектировать secondary DNS и контролируемые zone transfer.

Все изменения Netplan выполнять через netplan try при открытой консоли Proxmox. Перед изменением BIND создавать резервную копию, синхронизировать динамические зоны, выполнять named-checkconf -z и проверять live-ответы через dig.

Дополнение редакции 17 к следующим этапам:

при вводе каждого нового сегмента стандартизировать двухэлементный DNS suffix search list на клиентах;

для новых многосетевых Linux-сервисов использовать сегментные FQDN и шаблон ot-ddns-register;

при миграции файлового сервера на VLAN2030 перенести 172.16.66.229/23 с ens23 на ens21 и изменить интерфейс в его DDNS-скрипте;

после плановой перезагрузки SMR-SRV-OT-SHARE один раз проконтролировать boot-журнал ot-ddns-register.service;

по мере роста инфраструктуры повторно оценить необходимость BIND Views;

усилить аутентификацию RFC 2136 UPDATE отдельным проектом: TSIG, GSS-TSIG либо централизованный DHCP-DDNS.

Контрольная точка редакции 17: DDNS и эксплуатационные процедуры подтверждены во всех OT-сетях. Вся ранее проверенная конфигурация редакции 16 сохранена. Дополнительно подтверждена совместная работа BIND9 с многосетевым SMR-SRV-OT-SHARE: split DNS через systemd-resolved, пять сегментных FQDN, пять согласованных пар A/PTR через nsupdate и успешный systemd oneshot. Production management 10.44.100.228 доступен по SSH и Webmin из маршрутизируемой сети 10.44.0.0/21; фактический тест выполнен с 10.44.3.65. Зафиксирована целевая изоляция DNS-ВМ без Интернета, default route и системных DNS Ubuntu, с узкими статическими маршрутами к management и внутреннему NTP.