Skip to main content

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

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

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

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

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

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-зоны.

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.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-адрес
172.16.66.0/23 2030 Пивопроизводство 172.16.66.53
172.16.68.0/23 2002 Розлив 172.16.68.53
172.16.70.0/23 2040 Утилиты 172.16.70.53
172.17.14.0/24 2006 АСТУЭ 172.17.14.53
10.255.0.0/16 1 Legacy OT на переходный период 10.255.0.53

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

Этап Адрес Шлюз Назначение
Развёртывание 192.168.1.53/24 192.168.1.1 Временное управление, обновления и доступ в Интернет
Production 10.44.100.228/24 10.44.100.1 Постоянное управление сервером; default route пока не активирован

На сервере должен быть только один маршрут по умолчанию. Сейчас активен маршрут через ens18 → 192.168.1.1. Будущий маршрут через ens23 → 10.44.100.1 оставлен в Netplan комментарием.

4.4. Важное ограничение маршрутизации

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

net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

На OT-интерфейсах шлюзы не назначаются. Каждый OT-клиент обращается к DNS-адресу своей локальной подсети.

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

После окончательного перевода default route в production management планируются серверы:

10.44.14.34
10.44.14.33

Потребуется маршрут от 10.44.100.228 и разрешение UDP/123. Пока default route остаётся через ens18, эта замена не выполняется.

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
      link-local: []
      optional: true
      addresses:
        - 10.255.0.53/16
        - 172.16.66.53/23

    # Розлив, VLAN 2002 через Proxmox vmbr3 / nic1.2002.
    ens20:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      optional: true
      addresses:
        - 172.16.68.53/23

    # Будущее Пивопроизводство, VLAN 2030 через vmbr4 / nic1.2030.
    # Адрес нельзя включать, пока 172.16.66.53/23 назначен enp2s1.
    ens21:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      optional: true
      # addresses:
      #   - 172.16.66.53/23

    # Утилиты, VLAN 2040 через Proxmox vmbr5 / nic1.2040.
    ens22:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      optional: true
      addresses:
        - 172.16.70.53/23

    # Production management, VLAN 2100 через vmbr1 / nic1.2100.
    ens23:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      optional: true
      addresses:
        - 10.44.100.228/24

      # Будущий production default route.
      # Включается одновременно с удалением default route у ens18.
      # routes:
      #   - to: default
      #     via: 10.44.100.1
EOF

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.

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

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'

sudo ufw allow in on ens23 proto tcp \
  from 10.44.100.0/24 to 10.44.100.228 port 22 \
  comment 'SSH production management network'

sudo ufw enable
sudo ufw status verbose

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

Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)

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'

# Пивопроизводство, будущее подключение VLAN 2030
sudo ufw allow in on ens21 proto udp \
  from 172.16.66.0/23 to 172.16.66.53 port 53 \
  comment 'DNS beer production future VLAN2030 UDP'

sudo ufw allow in on ens21 proto tcp \
  from 172.16.66.0/23 to 172.16.66.53 port 53 \
  comment 'DNS beer production future VLAN2030 TCP'

# АСТУЭ, VLAN 2006
sudo ufw allow in on ens19 proto udp \
  from 172.17.14.0/24 to 172.17.14.53 port 53 \
  comment 'DNS ASTUE VLAN2006 UDP'

sudo ufw allow in on ens19 proto tcp \
  from 172.17.14.0/24 to 172.17.14.53 port 53 \
  comment 'DNS ASTUE VLAN2006 TCP'

sudo ufw reload
sudo ufw status numbered
sudo ufw show added

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

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

11.4. Предварительная проверка UFW до установки BIND9

На этом этапе BIND9 ещё не установлен, поэтому проверяются только правила firewall и запрет маршрутизации. Отсутствие процесса named, слушающего порта 53 и ответов dig здесь является ожидаемым состоянием.

# Проверяем активные правила и команды, которыми они были добавлены.
sudo ufw status numbered
sudo ufw show added

# Повторно убеждаемся, что ВМ не маршрутизирует трафик между OT-сетями.
sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

Команды systemctl is-active named, ss ... | grep named, journalctl -u named и запросы dig выполняются только после установки BIND9, создания зон и запуска службы — в разделе 18.

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 пока отсутствует.
    allow-transfer { none; };

    version "not disclosed";
    minimal-responses yes;
    auth-nxdomain no;
};
EOF

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;
};

zone "68.16.172.in-addr.arpa" {
    type master;
    file "/var/lib/bind/zones/db.68.16.172";
    allow-update { 172.16.68.0/23; };
    notify no;
};

zone "69.16.172.in-addr.arpa" {
    type master;
    file "/var/lib/bind/zones/db.69.16.172";
    allow-update { 172.16.68.0/23; };
    notify no;
};

zone "70.16.172.in-addr.arpa" {
    type master;
    file "/var/lib/bind/zones/db.70.16.172";
    allow-update { 172.16.70.0/23; };
    notify no;
};

zone "71.16.172.in-addr.arpa" {
    type master;
    file "/var/lib/bind/zones/db.71.16.172";
    allow-update { 172.16.70.0/23; };
    notify no;
};

zone "14.17.172.in-addr.arpa" {
    type master;
    file "/var/lib/bind/zones/db.14.17.172";
    allow-update { 172.17.14.0/24; };
    notify no;
};
EOF

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

Порядок выполнения: этот раздел выполняется только после завершения разделов 12–17: BIND9 установлен, глобальная конфигурация и файлы зон созданы, named-checkconf -z завершился успешно, а служба named запущена.

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

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. Правила редактирования зон

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

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

  1. открыть нужную зону в Серверы → Сервер DNS BIND;
  2. создать, изменить или удалить запись;
  3. сохранить изменение;
  4. убедиться, что зона снова имеет frozen: no;
  5. выполнить пользовательскую команду Синхронизировать DDNS-зоны;
  6. проверить запись через dig.

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

20.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

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

sudo rndc sync ot-samara.baltika.ru
sudo rndc sync 69.16.172.in-addr.arpa

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

20.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"

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

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

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

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

21.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

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

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

# Доступ через временный management-интерфейс ens18.
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-интерфейс ens23.
ufw allow in on ens23 \
  proto tcp \
  from 10.44.100.0/24 \
  to 10.44.100.228 \
  port 10000 \
  comment 'Webmin production management HTTPS'

ufw reload
ufw status numbered

Смысл ограничений: правило совпадает только при одновременном выполнении условий по входному интерфейсу, сети источника, локальному адресу назначения, протоколу TCP и порту 10000.

21.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.

21.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-сетями.

21.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

21.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:                   не используется

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

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

  1. выполнить Синхронизировать DDNS-зоны;
  2. создать временную TXT-запись webmin-dynamic-test;
  3. сохранить изменение через Webmin;
  4. проверить dynamic: yes и frozen: no;
  5. проверить TXT и существующие DDNS-записи через dig;
  6. удалить тестовую запись и повторить проверку.
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.

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

21.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.

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

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

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. Порядок просмотра

  1. запустить в Webmin Синхронизировать DDNS-зоны;
  2. закрыть и снова открыть страницу зоны;
  3. при необходимости выполнить обновление браузера Ctrl+F5;
  4. сверить запись с 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.

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-компьютера

  1. Утвердить имя компьютера и свободный статический IP по действующему плану адресации.
  2. На OT-интерфейсе задать IP, правильную маску и локальный DNS из таблицы выше; шлюз оставить пустым.
  3. В дополнительных параметрах IPv4 задать DNS-суффикс ot-samara.baltika.ru.
  4. Включить параметры «Зарегистрировать адреса этого подключения в DNS» и «Использовать DNS-суффикс этого подключения при регистрации».
  5. Отключить регистрацию адресов на Wi-Fi, VPN и других интерфейсах, которые не должны попадать в OT-зону.
  6. Запустить регистрацию и подождать 30–60 секунд.
  7. Проверить 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 в соответствующей обратной зоне.

  1. Проверить, что имя и IP не используются другим объектом.
  2. Открыть Серверы → BIND DNS Server → ot-samara.baltika.ru → Address Records.
  3. Создать A-запись с коротким именем без суффикса, например plc-fill-001, и фактическим IP.
  4. Открыть reverse-зону, соответствующую адресу, и создать PTR на полное имя с точкой в конце: plc-fill-001.ot-samara.baltika.ru.
  5. Запустить Check BIND Configuration, затем применить изменения.
  6. Проверить обе стороны через 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

  1. Назначить новый статический IP, маску и локальный DNS новой сети.
  2. Выполнить ipconfig /flushdns и ipconfig /registerdns.
  3. Проверить, что A указывает на новый IP и новый PTR указывает на текущее имя.
  4. В Webmin запустить 1. Текущие несовпадения PTR/A.
  5. Просмотреть отчёт и убедиться, что старый PTR действительно относится к перенесённому хосту.
  6. Запустить 2. Убрать текущие несовпадения PTR/A.
  7. Повторно проверить новый A/PTR и отсутствие старого PTR.

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

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

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

  1. перезагрузить компьютер после штатного переименования;
  2. выполнить ipconfig /registerdns;
  3. проверить A/PTR нового имени;
  4. через Webmin вручную удалить старую A-запись и связанные CNAME, если они больше не нужны;
  5. запустить отчёт PTR/A и удалить подтверждённый старый PTR;
  6. убедиться, что старое имя больше не разрешается.

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

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

  1. Убедиться, что IP и имя действительно освобождаются и не будут немедленно использованы другим устройством.
  2. Удалить A-запись из прямой зоны.
  3. Удалить PTR из соответствующей reverse-зоны.
  4. Удалить связанные CNAME и другие записи, указывающие на выводимый узел.
  5. Проверить через dig, что старое имя и старый PTR отсутствуют.
  6. Зафиксировать освобождение имени и IP в плане адресации.

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

  1. Открыть Прочие → Пользовательские команды.
  2. Запустить Синхронизировать DDNS-зоны.
  3. Повторно открыть нужную зону в модуле BIND.
  4. При необходимости выполнить Ctrl+F5.
  5. Сверить запись с dig.

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

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

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

  1. синхронизировать DDNS-зоны;
  2. создать резервную копию /etc/bind и /var/lib/bind/zones;
  3. убедиться, что зона не осталась замороженной после предыдущей операции;
  4. выполнить изменение через Webmin либо контролируемый цикл freeze → edit → check → thaw;
  5. проверить named-checkconf -z и live-ответы;
  6. проверить 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-проверка

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, перенос, переименование, удаление, диагностика и запрещённые действия

27. Текущее фактическое состояние

Компонент или проверка Подтверждённое состояние
Ubuntu Server 24.04.4 LTS, статическая многосетевая конфигурация Netplan применена
Proxmox/QEMU VirtIO-интерфейсы подключены к нужным bridge/VLAN; qemu-guest-agent активен
Маршрутизация Один default route через временный management; IP forwarding IPv4/IPv6 отключён
UFW DNS UDP/53 и TCP/53 разрешён только из соответствующих OT-сетей; SSH/Webmin — из management-сетей
BIND9 9.18.39, named активен; одна прямая и восемь 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 проверены
Известные особенности VPN/DNS-leak-фильтры могут блокировать локальный DNS; отдельно устранена неоднозначность MNAME reverse-зон

28. Следующие этапы

  1. создать и проверить контрольную резервную копию после внедрения локальных reverse MNAME/NS и всех DDNS-пилотов;
  2. утвердить промышленную схему именования и начать регистрацию рабочих Windows-хостов и ручных пар A/PTR для оборудования без DDNS;
  3. регулярно запускать отчёт PTR/A и выполнять очистку только под контролем изменений;
  4. усилить аутентификацию UPDATE: оценить TSIG, GSS-TSIG или централизованный DHCP-DDNS вместо доверия только по IP;
  5. ограничить Webmin встроенным IP Access Control и при необходимости установить доверенный внутренний TLS-сертификат;
  6. для клиентов, которым нужны корпоративные или внешние имена, отдельно спроектировать условную пересылку либо доверенный forwarder;
  7. настроить исключения AmneziaVPN для локальных OT-сетей и DNS либо отключать VPN при диагностике;
  8. выполнить атомарную миграцию 172.16.66.53/23 с enp2s1 на ens21 при вводе VLAN 2030 и удалить старые UFW-правила;
  9. перевести default route на production management после проверки SSH, Webmin и NTP;
  10. спроектировать secondary DNS и контролируемые zone transfer.

Все изменения Netplan выполнять через netplan try. Перед изменением BIND создавать резервную копию, синхронизировать динамические зоны, выполнять named-checkconf -z и проверять результат через dig.

Контрольная точка редакции 11: авторитетный BIND9, Webmin и DDNS настроены и проверены. A/PTR-регистрация подтверждена во всех пяти OT-сетях; reverse-зоны используют однозначные локальные MNAME/NS; синхронизация .jnl и очистка старых PTR доступны через проверенные пользовательские команды Webmin. Добавлен единый эксплуатационный регламент для повседневной работы операторов и инженеров. Проверки службы named, DNS-сокетов и end-to-end перенесены после установки и настройки BIND9, чтобы порядок инструкции соответствовал фактической последовательности развёртывания.

Back to top