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

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

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

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

Текущее состояние: BIND9 работает как выделенный авторитетный DNS для одной прямой и восьми обратных OT-зон; рекурсия и forwarder отключены. Доступ к DNS проверен с реальных Windows-клиентов во всех подключённых сетях. Webmin установлен и проверен как веб-интерфейс управления существующей конфигурацией BIND. DDNS пока выключен: во всех рабочих зонах используется allow-update { none; };.

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.	Свободное ПО под 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
  ↓ изменяет существующие конфигурационные файлы и файлы зон BIND
Проверка named-checkzone / named-checkconf
  ↓
rndc reload или Apply Configuration
  ↓
BIND9 начинает отвечать новой версией зоны

Webmin не заменяет BIND9 и не хранит отдельную базу DNS-записей: он управляет теми же файлами, которые можно проверять и обслуживать из Linux CLI. Поэтому после изменений всегда выполняются проверка синтаксиса и контрольный запрос через dig.

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

Этап	Как появляются записи
Сейчас	Все зоны статические, `allow-update { none; };`. Редкие записи оборудования добавляются вручную через Webmin или CLI.
Позднее	Windows-компьютеры со статическими IP и DNS-суффиксом `ot-samara.baltika.ru` смогут регистрировать свои A/PTR через DDNS. ПЛК, HMI, счётчики и другое оборудование без DDNS продолжат добавляться вручную.

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

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.

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`

network:
  version: 2
  renderer: networkd

  ethernets:
    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

    ens19:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      optional: true
      addresses:
        - 172.17.14.53/24

    enp2s1:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      optional: true
      addresses:
        - 10.255.0.53/16
        - 172.16.66.53/23

    ens20:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      optional: true
      addresses:
        - 172.16.68.53/23

    ens21:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      optional: true

      # Будущий адрес VLAN 2030.
      # Нельзя включать, пока этот адрес назначен enp2s1.
      # addresses:
      #   - 172.16.66.53/23

    ens22:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      optional: true
      addresses:
        - 172.16.70.53/23

    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

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. Проверка 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-сети.

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

Прямое и обратное разрешение проверено с Windows-клиентов через каждый локальный DNS-адрес. Команды выполняются в PowerShell, а не в Bash Ubuntu.

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

Шаблон проверки прямой записи:

Resolve-DnsName `
  -Name smr-srv-ot-dns.ot-samara.baltika.ru `
  -Type A `
  -Server <локальный-DNS-IP> `
  -DnsOnly

Шаблон проверки обратной записи:

Resolve-DnsName `
  -Name <локальный-DNS-IP> `
  -Type PTR `
  -Server <локальный-DNS-IP> `
  -DnsOnly

Проверка DNS по TCP:

Resolve-DnsName `
  -Name smr-srv-ot-dns.ot-samara.baltika.ru `
  -Type A `
  -Server <локальный-DNS-IP> `
  -DnsOnly `
  -TcpOnly

Test-NetConnection `
  -ComputerName <локальный-DNS-IP> `
  -Port 53 `
  -InformationLevel Detailed

В ответе на A-запрос возвращается один RRset из пяти адресов:

10.255.0.53
172.16.66.53
172.16.68.53
172.16.70.53
172.17.14.53

Порядок адресов в разных ответах может меняться. Это нормальное поведение DNS RRset и не означает приоритет одной сети над другой.

Каждый PTR-запрос к сервисному адресу возвращает:

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

Псевдоним dns.ot-samara.baltika.ru также проверен: сервер возвращает CNAME на smr-srv-ot-dns.ot-samara.baltika.ru, затем пять A-записей.

Во время диагностики используется захват на конкретном интерфейсе:

sudo tcpdump -ni enp2s1 -vv 'port 53'
sudo tcpdump -ni ens20  -vv 'port 53'
sudo tcpdump -ni ens22  -vv 'port 53'
sudo tcpdump -ni ens19  -vv 'port 53'
# После миграции VLAN 2030:
sudo tcpdump -ni ens21  -vv 'port 53'

На 10.255.0.53 захват подтвердил полный обмен UDP и TCP: запрос клиента пришёл через enp2s1, BIND вернул авторитетный ответ, TCP handshake завершился, а DNS-запрос по TCP получил пять A-записей.

Единичный тайм-аут: первый UDP-запрос к 172.16.68.53 один раз завершился по тайм-ауту, повторный A-запрос и PTR прошли успешно. При стабильных повторных ответах это трактуется как разовая потеря UDP-пакета или переходное состояние клиента, а не как ошибка зоны, BIND или UFW.

11.6. Диагностика 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.

11.7. Ожидаемый 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 не гарантирует разделение запросов по зонам.

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

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

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.options`

// Сети, которым разрешено обращаться к авторитетным OT-зонам.
acl "ot-clients" {
    localhost;
    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;
};

options {
    directory "/var/cache/bind";

    listen-on {
        127.0.0.1;
        10.255.0.53;
        172.16.66.53;
        172.16.68.53;
        172.16.70.53;
        172.17.14.53;
    };

    listen-on-v6 { none; };

    allow-query {
        ot-clients;
    };

    recursion no;
    allow-query-cache { none; };
    dnssec-validation no;

    allow-transfer { none; };

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

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

Параметр	Назначение
`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`

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

forwarders { ... };
forward only;

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

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. Прямая зона

Файл /var/lib/bind/zones/db.ot-samara.baltika.ru:

$ORIGIN ot-samara.baltika.ru.
$TTL 3600

@      IN      SOA     smr-srv-ot-dns.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (
                       2026072901
                       3600
                       900
                       1209600
                       300 )

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

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

dns                 IN  CNAME   smr-srv-ot-dns

После редактирования через Webmin SOA serial должен увеличиться. Webmin может выровнять формат SOA и удалить комментарии возле числовых полей; для BIND это эквивалентное представление, поскольку пробелы и комментарии не влияют на DNS-данные.

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

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

Текущее значение:

hostmaster.ot-samara.baltika.ru.

Оно соответствует адресу hostmaster@ot-samara.baltika.ru. Поле является опубликованным контактом и не используется BIND для автоматической отправки почты.

Рабочий адрес perelygin_mv@baltika.com в SOA записывается так:

perelygin_mv.baltika.com.

При замене контакта нужно увеличить serial относительно текущего значения, например YYYYMMDD00 → YYYYMMDD01, проверить зону и перечитать её:

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

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

Каждая обратная зона содержит собственные SOA и NS. Пример файла db.66.16.172:

$TTL 3600

@   IN  SOA smr-srv-ot-dns.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (
        2026072401
        3600
        900
        1209600
        300
)

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

Для адреса 10.255.0.53 в зоне 255.10.in-addr.arpa используется владелец 53.0:

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

Для сети АСТУЭ создан файл /var/lib/bind/zones/db.14.17.172:

$TTL 3600

@   IN  SOA smr-srv-ot-dns.ot-samara.baltika.ru. hostmaster.ot-samara.baltika.ru. (
        2026072702 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        300        ; negative cache TTL
)

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

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

Короткий владелец 53 внутри зоны 14.17.172.in-addr.arpa формирует полное имя 53.14.17.172.in-addr.arpa, соответствующее адресу 172.17.14.53.

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

zone "ot-samara.baltika.ru" {
    type master;
    file "/var/lib/bind/zones/db.ot-samara.baltika.ru";
    allow-update { none; };
    notify no;
};

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

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

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

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

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

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

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

// АСТУЭ: 172.17.14.0/24, VLAN 2006.
zone "14.17.172.in-addr.arpa" {
    type master;
    file "/var/lib/bind/zones/db.14.17.172";
    allow-update { none; };
    notify no;
};

allow-update { none; }; запрещает DDNS. notify no; отключает уведомления, потому что secondary DNS пока отсутствует.

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

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

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

Ожидается:

zone ot-samara.baltika.ru/IN: loaded serial <актуальный_serial>
OK

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 обратной зоны с serial 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. Важный нюанс нескольких A-записей DNS-сервера

Имя smr-srv-ot-dns.ot-samara.baltika.ru сейчас имеет пять A-записей: 10.255.0.53, 172.16.66.53, 172.16.68.53, 172.16.70.53 и 172.17.14.53. Это корректно для обычных авторитетных ответов, но между OT-подсетями отсутствует маршрутизация.

При будущем DDNS Windows-клиент может получить SOA MNAME, разрешить его в один из пяти адресов и выбрать адрес другой, недоступной подсети. Поэтому DDNS нельзя включать простым широким allow-update без проектного решения.

До включения DDNS нужно выбрать один из вариантов:

BIND views с разными ответами для разных сетей;
отдельные DNS-имена primary-сервера для каждого VLAN;
маршрутизация между OT-подсетями;
централизованные обновления через DHCP и TSIG.

Разрешение DDNS только по IP-адресу клиента без TSIG не обеспечивает аутентификацию. Любой узел с разрешённым адресом сможет изменять записи зоны.

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

Пока используется allow-update { none; };, файл зоны можно редактировать вручную. После каждого изменения:

увеличить SOA serial;
выполнить named-checkzone;
перечитать нужную зону через rndc reload;
проверить запись через dig.

sudo named-checkzone ot-samara.baltika.ru /var/lib/bind/zones/db.ot-samara.baltika.ru
sudo rndc reload ot-samara.baltika.ru
dig @127.0.0.1 ot-samara.baltika.ru SOA +norecurse

При статической зоне Webmin может сам выполнить защитную команду freeze, сохранить запись, увеличить SOA serial и перечитать конфигурацию. Это было подтверждено журналом named во время теста TXT-записи.

После включения DDNS появятся файлы .jnl. Тогда прямое редактирование работающей динамической зоны запрещается. Используется:

sudo rndc freeze ot-samara.baltika.ru
# редактирование файла и увеличение serial
sudo rndc thaw ot-samara.baltika.ru

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

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

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

На текущем этапе Webmin используется для просмотра конфигурации и редких ручных изменений записей. DDNS не включён. При будущем включении динамических обновлений ручное редактирование динамической зоны выполняется только по схеме Freeze → Edit → Check → Unfreeze.

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 доступен только через временную и 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.

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 означает полное совпадение списков.
diff -u \
  /root/bind-before-webmin.sha256 \
  /root/bind-after-webmin.sha256

named-checkconf -z
systemctl is-active named

grep -Rni \
  --include='named.conf*' \
  'allow-update' \
  /etc/bind

Проверка успешна: Webmin не изменил 21 контролируемый файл BIND, все зоны загрузились, named остался активен, а во всех девяти рабочих зонах сохранилось allow-update { none; };.

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: сначала проверяются пути модуля. В этой установке существующие зоны обнаружены корректно.

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

После того как Webmin обнаружил существующие зоны, выполняется один безопасный тест записи. Он подтверждает, что веб-интерфейс изменяет правильный файл, увеличивает SOA serial и корректно перечитывает BIND.

Создать временную TXT-запись webmin-test.ot-samara.baltika.ru со значением webmin-write-test. Индивидуальный TTL можно не задавать — тогда применяется глобальный $TTL зоны.
Нажать Apply Configuration.
Проверить файл зоны, синтаксис и авторитетный ответ.
Удалить тестовую запись, снова применить конфигурацию и убедиться, что запрос возвращает NXDOMAIN.

# Ищем тестовую строку в файле; -n показывает номер строки.
grep -n 'webmin-test' /var/lib/bind/zones/db.ot-samara.baltika.ru

# Проверяем синтаксис одной зоны.
named-checkzone \
  ot-samara.baltika.ru \
  /var/lib/bind/zones/db.ot-samara.baltika.ru

# Проверяем все include-файлы и загрузку всех зон.
named-checkconf -z

# Запрашиваем TXT без рекурсии и оставляем в выводе заголовок и ANSWER.
dig @127.0.0.1 \
  webmin-test.ot-samara.baltika.ru \
  TXT \
  +norecurse \
  +noall \
  +comments \
  +answer

Ожидаемый результат после создания: named-checkzone возвращает OK, dig — NOERROR и флаг aa, а SOA serial становится больше предыдущего. После удаления ожидается авторитетный NXDOMAIN.

На этом сервере полный цикл создания и удаления тестовой TXT-записи выполнен успешно. Тестовая запись удалена. Webmin может выровнять формат SOA и убрать комментарии из файла зоны; DNS-данные при этом не меняются.

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

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

Компонент или проверка	Подтверждённое состояние
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 TCP/10000 — только из management-сетей
BIND9	9.18.39, `named` активен; одна прямая и восемь обратных рабочих зон проходят `named-checkconf -z`
Режим DNS	Авторитетный сервер без рекурсии и forwarder; внешние имена получают ожидаемый `REFUSED`
Webmin	2.653 из official stable repository; существующая конфигурация BIND и все зоны обнаружены; создание и удаление тестовой TXT-записи проверены
DDNS	Выключен; во всех девяти рабочих зонах сохранено `allow-update { none; };`
DNS-функции	A, PTR и CNAME проверены через все пять сервисных адресов; подтверждена работа UDP/53 и TCP/53 с реальных Windows-клиентов
Известная особенность клиентов	VPN-клиенты с защитой от DNS leak могут блокировать локальный DNS; это проверяется через `tcpdump` на сервере и отключение/исключения VPN на клиенте

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

ограничить доступ дополнительным встроенным IP Access Control Webmin для сетей 192.168.1.0/24 и 10.44.100.0/24; оценить отключение ненужного IPv6-listener;
при необходимости заменить локальный сертификат Webmin на доверенный внутренний сертификат;
утвердить схему именования OT-оборудования и начать добавление рабочих пар A/PTR для ПЛК, HMI, счётчиков, серверов и инженерных станций через Webmin;
для клиентов, которым нужны корпоративные или внешние имена, выбрать модель разрешения: условная пересылка конкретных зон либо доверенный forwarder; не превращать авторитетный сервер в открытый recursive resolver;
настроить в AmneziaVPN постоянное исключение локальной сети и OT-DNS, чтобы VPN не блокировал локальные UDP/53 и TCP/53;
после появления тестового узла в VLAN 2030 выполнить атомарную миграцию адреса 172.16.66.53/23 с enp2s1 на ens21, затем удалить устаревшие UFW-правила на enp2s1;
перевести default route с временного management на production management после проверки маршрутизации, SSH и NTP;
позднее включить DDNS для статически адресованных Windows-хостов только после отдельного теста схемы SOA MNAME и процедуры Freeze → Edit → Unfreeze; DNS-суффикс задавать через GUI Windows;
спроектировать secondary DNS и разрешить контролируемые zone transfer.

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

Контрольная точка редакции 7: авторитетный BIND9 и Webmin установлены, настроены и проверены. Все рабочие зоны загружаются, A/PTR/CNAME и оба транспорта DNS подтверждены с OT-клиентов, доступ к Webmin ограничен management-сетями. DDNS остаётся выключенным до отдельного этапа.

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

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

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

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

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

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

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

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

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

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

3. План DNS-зон

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. QEMU Guest Agent

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

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

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

9.3. Проверка

9.4. Production NTP

10. Netplan

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

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

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

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

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

11.1. IP forwarding

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

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

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

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

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

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

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

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

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

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

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

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

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

14. Файлы зон

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

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

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

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

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

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

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

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

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

15.4. A и AAAA

15.5. CNAME

15.6. PTR

15.7. MX

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

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

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

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

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

17.1. SOA

17.2. NS

17.3. A и CNAME

17.4. PTR

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

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

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

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

13.1. Файл `/etc/bind/named.conf.options`

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