Бэкап и восстановление Technitium DNS

MAATRIX

Technitium DNS Server — редкий случай, когда полноценный рекурсивный резолвер, авторитативный DNS с DNSSEC, DHCP-сервер и панель блокировки рекламы живут в одном .NET-приложении с удобной веб-консолью. Именно поэтому бэкап здесь не сводится к копированию одного YAML-файла: потерять можно не только правила блокировки, а зоны, которые вы сами обслуживаете, DNSSEC-ключи подписи и TSIG-секреты для передачи зон между серверами. Ниже — что именно копировать, как это делает встроенный механизм бэкапа панели, и как автоматизировать процесс, если панель недоступна.

Что хранит Technitium DNS Server и почему бэкап — это не один файл

Все настройки Technitium DNS Server лежат в рабочей директории config, которую сервер создаёт относительно каталога, откуда запущен процесс. В типичной установке через systemd рабочим каталогом выступает /etc/dns, поэтому фактические файлы оказываются в /etc/dns/config — точный путь свериться на вашем сервере командой systemctl cat dns и посмотреть строки WorkingDirectory= и ExecStart=, в разных версиях установочного скрипта путь мог отличаться.

Внутри config лежит несколько категорий данных, и у каждой свой уровень критичности:

Ключевой нюанс: dns.config — не текстовый YAML или JSON, а бинарный формат, который сервер пишет сам через веб-консоль или API. Ручное редактирование не предусмотрено, поэтому при повреждении или потере файла единственный путь назад — бэкап, а не восстановление настроек по памяти, как это условно возможно с named.conf в BIND9 или конфигом PowerDNS.

Встроенный бэкап и восстановление через веб-консоль

У Technitium DNS Server есть то, чего часто не хватает похожим проектам вроде AdGuard Home — штатный экран бэкапа прямо в панели, без ручного копирования файлов с сервера.

Зайдите в веб-консоль (по умолчанию порт 5380) → Settings → вкладка Backup & Restore. Там — список чекбоксов, что включить в архив:

• Config — основной конфиг сервера, включая TSIG-ключи и настройки протоколов;
• Logs — файлы логов запросов;
• Zones — все авторитативные зоны вместе с DNSSEC-ключами;
• Allowed zones и Blocked zones — ручные списки разрешений/блокировок;
• Apps — установленные приложения панели вместе с их настройками;
• Stats — статистика запросов;
• Scopes — DHCP-области, если сервер используется и как DHCP-сервер.

Отмечаете нужное, жмёте Backup — панель формирует ZIP-архив и отдаёт его на скачивание браузером. Для регулярного бэкапа разумный минимум — Config, Zones, Allowed/Blocked zones и Apps; Logs и Stats можно исключить, если вам не нужна история для расследований, это заметно уменьшает размер архива.

Восстановление — там же, вкладка Restore: загружаете ZIP, отмечаете, что восстанавливать, и подтверждаете. Панель сама остановит нужные внутренние процессы, распакует данные на место и, если восстанавливали Config, предложит перезапустить сервер. Это самый безопасный способ восстановления, потому что панель сама следит за совместимостью формата данных с текущей версией — в отличие от прямой подмены файлов на диске.

Бэкап через API — автоматизация без входа в панель

Ручной клик по кнопке "Backup" не годится для регулярного расписания. У Technitium DNS Server есть полноценный HTTP API, и та же функция доступна через него — эндпоинт /api/settings/backup с токеном авторизации (постоянный API-токен выпускается в разделе Administration → Sessions) и набором query-параметров, повторяющих чекбоксы панели (config, logs, zones, allowedZones, blockedZones, apps, stats, scopes). Точные имена параметров лучше свериться прямо на сервере — в панели есть страница Help → API Docs, сгенерированная под установленную версию.

Общая схема curl-запроса для скрипта:

#!/usr/bin/env bash
set -euo pipefail

API_HOST="http://127.0.0.1:5380"
API_TOKEN="ваш_api_token"
DEST="/root/backups/technitium"
STAMP=$(date +%Y%m%d-%H%M%S)

mkdir -p "$DEST"

curl -fsS "${API_HOST}/api/settings/backup?token=${API_TOKEN}&config=true&zones=true&allowedZones=true&blockedZones=true&apps=true&scopes=true&logs=false&stats=false" \
  -o "$DEST/technitium-$STAMP.zip"

echo "Бэкап готов: $DEST/technitium-$STAMP.zip"

Такой скрипт можно дёргать по cron и не открывать браузер вовсе. Если API слушает не только loopback, ограничьте доступ к порту 5380 фаерволом — токен в query-параметре иначе может утечь через логи прокси.

Файловый бэкап на уровне сервера

API и панель покрывают почти всё, но иногда нужен именно файловый снапшот — например, при переносе на новое железо вместе с TLS-сертификатами для DoH/DoT: сертификаты, подключённые как файлы на диске, а не выпущенные встроенным Let's Encrypt-клиентом панели, остаются вне ZIP.

Bare-metal установка (systemd-юнит dns.service), с остановкой сервиса ради консистентного снапшота:

systemctl stop dns
tar czf /root/backups/technitium-fs-$(date +%Y%m%d-%H%M).tar.gz -C /etc/dns config
systemctl start dns

Docker-развёртывание (образ technitium/dns-server), где конфиг обычно смонтирован снаружи в /etc/dns контейнера:

services:
  dns-server:
    image: technitium/dns-server:latest
    container_name: dns-server
    hostname: dns-server
    restart: unless-stopped
    ports:
      - "5380:5380/tcp"
      - "53:53/udp"
      - "53:53/tcp"
      - "853:853/tcp"
      - "853:853/udp"
      - "443:443/tcp"
    volumes:
      - ./config:/etc/dns/

Бэкап тут — это просто копия каталога ./config на хосте, остановка контейнера при этом не обязательна для консистентности текстовых частей, но безопаснее сделать docker compose stop dns-server на время копирования, если сервер активно пишет статистику и логи в этот момент. Общие грабли с правами и именованными томами вместо bind-mount разобраны в статье про бэкап Docker volume.

Если хочется не голых tar-архивов с ротацией по дате, а версионирования с дедупликацией — заведите restic прямо поверх /etc/dns/config, а офсайт-копию отправляйте через rclone в объектное хранилище — оба инструмента работают с любым каталогом, не завязаны на формат конфига конкретного DNS-сервера.

Восстановление: пошагово и на чём спотыкаются

Порядок действий зависит от того, каким способом делали бэкап.

Через ZIP из веб-консоли (предпочтительный способ для типового восстановления):

1. Установите Technitium DNS Server на новый сервер тем же способом (systemd-скрипт или тот же Docker-образ), дайте панели создать чистый config при первом старте.
2. Зайдите в панель под временными учётными данными, откройте Settings → Backup & Restore → Restore.
3. Загрузите ZIP-архив, отметьте компоненты для восстановления — обычно всё, что было в бэкапе.
4. Подтвердите — панель распакует данные и предложит перезапуск сервиса.
5. Проверьте резолвинг: dig @127.0.0.1 example.com и откройте авторитативные зоны в разделе Zones, чтобы убедиться, что записи и DNSSEC-статус зоны на месте.

Через файловый архив (когда бэкапили tar):

1. Остановите сервис на новом сервере: systemctl stop dns.
2. Распакуйте архив поверх рабочего каталога: tar xzf technitium-fs-*.tar.gz -C /etc/dns.
3. Проверьте владельца файлов — если сервис работает не от root (частая практика в systemd-юните с User=), после распаковки от root потребуется chown -R <пользователь>:<группа> /etc/dns/config, иначе процесс не сможет писать в свои же файлы.
4. Запустите сервис: systemctl start dns и проверьте логи journalctl -u dns -n 50 на ошибки чтения конфига.

Отдельно про DNSSEC. Если восстанавливаемый сервер был подписывающим (Primary) для зоны с DNSSEC, а бэкап зон не включал ключи (бэкапили только Config, без Zones) — зона на новом сервере окажется без DNSSEC-ключей вообще. Резолверы, которые уже закэшировали DS-запись у регистратора, начнут получать ответы без валидной подписи и будут считать зону поддельной. Восстанавливайте Zones вместе с Config всегда, если используете DNSSEC, и сверьте, что KSK/DS-запись у регистратора совпадает с тем, что показывает раздел зоны в панели.

Отдельно про TSIG. Ключ для передачи зон между Primary и Secondary хранится в Config. Если Secondary тоже переустанавливали из отдельного бэкапа — сверьте, что имя и секрет TSIG-ключа на обеих сторонах совпадают буквально, иначе получите молчаливый отказ AXFR/IXFR без явной ошибки в интерфейсе.

Частые ошибки

• Бэкапили только Config, не Zones. Работает резолвинг через forwarders, но пропадают авторитативные зоны и DNSSEC-ключи к ним — это разные разделы бэкапа, отмечать нужно оба, если держите свои домены на сервере.
• Полагались только на кнопку в панели и не проверяли восстановление ни разу. Формат ZIP-архива специфичен для версии сервера — раз в квартал стоит реально развернуть архив на тестовом сервере, а не просто убедиться, что файл скачался.
• Хранили единственную копию бэкапа на том же диске, где стоит сам DNS-сервер. При отказе диска теряете и сервис, и его бэкап одновременно — копия обязана улетать на другую машину или в объектное хранилище.
• API-токен в открытом виде в скрипте бэкапа под git. Токен от /api/settings/backup даёт доступ к полному конфигу сервера, включая TSIG-секреты — храните его как секрет, а не как обычную переменную в репозитории.
• Забыли про TLS-сертификаты для DoH/DoT, подключённые вручную как файлы на диске, а не через встроенный ACME-клиент панели. Панельный и API-бэкап их не подхватывают — нужен отдельный файловый бэкап каталога с сертификатами или перевыпуск на новом сервере.

Частые вопросы