Technitium DNS на сервере: частые ошибки и решения

MAATRIX

Technitium DNS Server выбирают за то, что это полноценный DNS-сервер с веб-панелью «из коробки»: рекурсивный резолвер, авторитативные зоны, блокировка рекламы, DoH/DoT, DNSSEC — без ручной правки конфигов BIND или Unbound. Но именно из-за этой универсальности новичок в первые же полчаса натыкается на набор одних и тех же ошибок: порт 53 занят, панель на 5380 недоступна снаружи, блокировки не срабатывают, а DNSSEC вместо защиты просто рвёт резолвинг. Разбираем каждую по схеме «симптом — причина — решение».

Служба не стартует: порт 53 уже занят

Классика после curl -sSL https://download.technitium.com/dns/install.sh | sudo bash на свежем Ubuntu/Debian — сервис dns.service падает или DNS не отвечает, хотя веб-панель вроде поднялась. В логе journalctl -u dns -n 50 будет что-то вроде Address already in use на 53-м порту.

Причина почти всегда одна — systemd-resolved уже держит 53/udp и 53/tcp:

sudo ss -tulnp | grep ':53'

Если видите systemd-resolve, отключаете встроенный DNS-стаб, не трогая сам systemd-resolved (он ещё нужен для резолвинга имени хоста):

sudo sed -i 's/#DNSStubListener=yes/DNSStubListener=no/' /etc/systemd/resolved.conf
sudo systemctl restart systemd-resolved
sudo rm -f /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo systemctl restart dns

После этого resolv.conf будет указывать на 127.0.0.53, а сам Technitium спокойно займёт 53-й порт под внешние запросы. Проверка:

sudo systemctl status dns
dig @127.0.0.1 example.com +short

Если сервис всё равно не стартует, а порт свободен — почти всегда дело в правах на бинарник после ручного обновления: chmod +x /opt/technitium/dns/DnsServerApp и chown -R dns:dns /etc/dns (пути могут отличаться в зависимости от способа установки — deb-пакет кладёт конфиг в /etc/dns, ручная установка — в каталог рядом с бинарником).

Веб-панель на 5380 не открывается снаружи

Локально curl http://127.0.0.1:5380 отвечает, а с другого компьютера браузер висит и таймаутится. Три типичные причины по порядку проверки:

1. Файрвол на сервере. Порт 5380 не открыт для входящих:

sudo ufw allow 5380/tcp comment 'Technitium web console'
sudo ufw status

1. Security group у облачного провайдера — правило файрвола внутри ОС может быть открыто, но провайдер режет трафик на уровне сети раньше. Проверьте отдельно в панели хостинга.
2. Панель слушает не на всех интерфейсах. Если при установке указывали конкретный IP, а не 0.0.0.0, панель отвечает только на loopback. В /etc/dns/dns.config (или через саму панель — Settings → General → Web Service Local Addresses) выставьте 0.0.0.0, затем перезапустите сервис.

Отдельная ловушка — самоподписанный TLS-сертификат панели, если включили HTTPS для консоли (Settings → General → Enable HTTPS for Web Console): браузер молча блокирует запрос, пока вы явно не примете предупреждение о сертификате, либо сразу настройте Let's Encrypt на реверс-прокси перед панелью — это надёжнее, чем гонять самоподписанный сертификат.

Дефолтные креды admin/admin и вход в панель

При первом заходе Technitium требует задать пароль администратора — если вы это пропустили и сервер уже «в бою», а кто-то успел зайти под дефолтным admin/admin (актуально для старых версий, где смена пароля не была обязательной на первом шаге), сбросить пароль можно только через файл. Остановите сервис, отредактируйте /etc/dns/dns.config — там хранится хэш пароля, проще пересоздать пользователя из панели восстановления или удалить файл конфигурации пользователей и пройти первичную настройку заново:

sudo systemctl stop dns
sudo mv /etc/dns/config /etc/dns/config.bak
sudo systemctl start dns

Это откатит панель к первому запуску (зоны и логи не трогает, но пересоздаёт пользователей и настройки веб-сервиса) — открывайте http://ваш-ip:5380 и задавайте новый пароль сразу. Держать сервис с дефолтным паролем в интернете — прямой путь к тому, что кто-то перепишет вам forwarders на свои.

Блокировка рекламы включена, но не работает

Отличие Technitium от AdGuard Home в том, что базовой блокировки «из коробки» нет — нужно явно включить приложение Advanced Blocking (Apps → App Store → Advanced Blocking → Install) и подключить списки блокировки в Settings → Blocking:

https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
https://big.oisd.nl/

Частые причины, почему после этого домены всё равно резолвятся:

• Списки не обновились. По умолчанию интервал обновления Block Lists — 24 часа. Нажмите Settings → Blocking → Update Block Lists вручную и проверьте статус в логах — при первой загрузке больших списков (oisd, несколько сотен тысяч строк) процесс может занять пару минут, это нормально.
• Клиент обращается не через Technitium. Проверяйте не с самого сервера (там резолвинг может идти в обход, через /etc/resolv.conf на 127.0.0.53), а с клиентского устройства: nslookup doubleclick.net ваш-ip-сервера. Домен из блок-листа должен вернуть 0.0.0.0 или NXDOMAIN в зависимости от режима блокировки.
• Allow List перебивает Block List. Если в Settings → Blocking → Allowed Zones есть домен или широкая маска — он имеет приоритет. Проверьте список разрешений отдельно.
• DoH/DoT в браузере обходит сервер. Firefox и Chrome с включённым «Secure DNS» по умолчанию уходят к Cloudflare/Google напрямую, игнорируя DNS, который выдал DHCP. Отключите Secure DNS в браузере или явно пропишите свой Technitium как кастомный DoH-провайдер — иначе любая блокировка на сервере бессмысленна.

DoH/DoT не поднимается или недоступен снаружи

DNS-over-HTTPS и DNS-over-TLS в Technitium включаются в Settings → Optional Protocols, но там же обычно и спотыкаются:

Settings → Optional Protocols
☑ DNS-over-TLS (порт 853)
☑ DNS-over-HTTPS (порт 443 или 8053)

Без валидного TLS-сертификата оба протокола либо не стартуют, либо клиенты (браузеры, приложения на телефоне) отказываются подключаться из-за самоподписанного сертификата. Рабочих варианта два:

1. Импортировать сертификат прямо в Technitium — Settings → Optional Protocols → загрузить PFX-файл, полученный, например, через certbot и упакованный в PKCS#12:

openssl pkcs12 -export -out cert.pfx \
  -inkey /etc/letsencrypt/live/dns.example.com/privkey.pem \
  -in /etc/letsencrypt/live/dns.example.com/fullchain.pem

1. Поставить реверс-прокси перед DoH (Caddy или Nginx на 443-м порту с автообновляемым сертификатом), проксируя /dns-query на внутренний порт Technitium (обычно 8053) — этот путь проще для автопродления и описан в статье про Caddy с авто-SSL.

Отдельно проверьте, что порты 443/853 не заняты другим сервисом (Nginx, Apache) и что они реально открыты наружу — DoT на 853/tcp часто забывают добавить в файрвол отдельно от 443:

sudo ufw allow 853/tcp comment 'Technitium DoT'
sudo ufw allow 443/tcp comment 'Technitium DoH'

DNSSEC валидация рвёт резолвинг части доменов

Включили DNSSEC-валидацию (Settings → DNS → DNSSEC Validation) — и часть сайтов вдруг перестала открываться с ошибкой SERVFAIL. Это не баг Technitium, а корректная работа валидатора: у сайта либо просрочена подпись зоны, либо неправильно настроен DS-record в родительской зоне, либо часовой пояс на сервере съехал и подписи считаются «ещё не начавшимися» или «уже истёкшими».

Диагностика конкретного домена:

dig +dnssec example.com
kdig +dnssec +multi example.com

Если время на сервере действительно уехало — это первое, что нужно проверить, DNSSEC крайне чувствителен к системным часам:

timedatectl status
sudo systemctl restart systemd-timesyncd

Если время в порядке, а сайт всё равно валится — проблема на стороне владельца домена (битая цепочка доверия), и это не лечится на вашей стороне. Временный обход — добавить конкретный домен в Negative Trust Anchor (Settings → DNSSEC → NTA), но это осознанное решение отключить проверку для одного домена, а не для всего сервера.

Отдельно проверьте, что forwarder (если он настроен вместо чистой рекурсии) сам поддерживает DNSSEC и не режет флаг AD — иначе валидация локально включена, но бессмысленна, потому что апстрим уже отдаёт нефильтрованный ответ без данных для проверки подписи.

Вторичные зоны не синхронизируются, зона не резолвится

Если Technitium используется как авторитативный сервер для собственных доменов и настроена схема Primary/Secondary (либо второй Technitium, либо BIND/PowerDNS в паре), частая ошибка — вторичная зона не тянет обновления, в логе Zone transfer failed или REFUSED.

Проверьте по порядку:

• ACL передачи зоны на Primary. В настройках зоны (Zone → Options → Zone Transfer) должен быть явно указан IP вторичного сервера или диапазон, иначе Primary отвечает REFUSED на любой AXFR/IXFR-запрос.
• NOTIFY отключён или не доходит. Если после изменения записи вторичная зона не подхватывает обновление сама, а только по таймеру SOA — проверьте, что Zone → Options → Notify включён и не блокируется файрволом (тот же 53-й порт, TCP).
• Serial не увеличился. Технитиум, как и любой DNS-сервер, ориентируется на SOA serial — если вы правили записи через API или напрямую в файле зоны, а не через панель, serial может остаться прежним, и вторичный сервер решит, что обновлять нечего.

Ручная проверка передачи зоны с самого сервера:

dig axfr example.com @ip-primary-servera

Если команда возвращает Transfer failed, значит дело в ACL или файрволе, а не в самой зоне.

Логи, память и диагностика

Technitium написан на .NET и под нагрузкой (большие блок-листы, много одновременных клиентов) ест заметно больше памяти, чем Unbound или dnsmasq — это плата за веб-панель, приложения и хранение полной статистики. Для сервера с 5-10 клиентами и блок-листом на пару сотен тысяч записей ориентируйтесь на 1-2 ГБ RAM с запасом; точная цифра зависит от объёма списков и глубины хранения Query Logs, поэтому воспринимайте это как отправную точку, а не гарантию.

Если сервис регулярно падает по OOM, в первую очередь сократите глубину хранения логов запросов (Settings → Logging → Query Logs) — по умолчанию они пишутся в файл и разрастаются на активном сервере, либо переключите Query Logs на внешний экспорт через приложение Log Exporter вместо локального хранения.

Основные логи для диагностики:

tail -f /etc/dns/logs/*.log
journalctl -u dns -f

В самой панели раздел Dashboard → Logs показывает последние ошибки без похода в консоль — обычно этого достаточно, чтобы понять, что происходит: отказ форвардера, таймаут апстрима или переполнение кэша.

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