Technitium DNS Server: мощный DNS-сервер, который незаслуженно мало знают

DNS обычно вспоминают тогда, когда он перестал работать.

Пользователь говорит: «Интернет есть, сайты не открываются». Сетевик смотрит ping до 8.8.8.8. Пинг есть. Значит, виноват DNS.

Дальше начинается классика. Перезагрузить роутер. Перезагрузить компьютер. Поменять DNS на 8.8.8.8. Потом на 1.1.1.1. Потом кто-то предлагает «поставить Pi-hole».

А можно сделать иначе.

Можно поставить полноценный DNS-сервер, который умеет быть одновременно рекурсивным resolver’ом, authoritative DNS, фильтром рекламы и malware, сервером локальных зон, точкой централизованного DNS-контроля и шлюзом к DoH, DoT или DoQ.

Один из таких вариантов — Technitium DNS Server.

Причём это не очередная маленькая утилита для Raspberry Pi. Technitium поддерживает authoritative и recursive DNS, DNSSEC, DNS over HTTPS, DNS over TLS, DNS over QUIC, clustering, OIDC SSO, DHCP, API, DNS Apps и большое количество современных DNS-механизмов.

На момент публикации актуальна версия 15.4. Перед установкой проверь свежие релизы на официальном сайте Technitium.

1. Что такое Technitium DNS Server

Technitium DNS Server — кроссплатформенный open source DNS-сервер.

Он может работать как recursive DNS resolver, когда сам проходит цепочку DNS-запросов от root-серверов до authoritative DNS, и как authoritative DNS server, когда отвечает за собственные DNS-зоны.

Это уже отличает его от многих популярных домашних решений.

Например, Pi-hole чаще воспринимают как DNS-фильтр с удобной статистикой. AdGuard Home тоже в первую очередь воспринимается как DNS-фильтр для сети.

Technitium смотрит на задачу шире.

Перед тобой фактически полноценная DNS-платформа.

Что умеет Technitium

• recursive DNS resolution;
• authoritative DNS;
• DNSSEC validation и DNSSEC signed zones;
• DNS-over-TLS;
• DNS-over-HTTPS;
• DNS-over-QUIC;
• DNS caching;
• persistent cache;
• prefetching и serve stale;
• DNS filtering;
• DNS sinkhole;
• локальные DNS-зоны;
• conditional forwarding;
• split horizon;
• geolocation-based DNS responses через DNS Apps;
• DHCP;
• DNS API;
• 2FA;
• RBAC;
• clustering;
• OIDC SSO;
• AXFR/IXFR;
• DDNS;
• TSIG;
• XFR-over-TLS;
• XFR-over-QUIC.

Полный список возможностей заметно длиннее. Официальная документация прямо позиционирует Technitium как сервер, который можно использовать и для recursive, и для authoritative DNS.

2. Зачем вообще поднимать собственный DNS

Первый вопрос обычно звучит так:

«Зачем мне свой DNS? Есть же 1.1.1.1 и 8.8.8.8».

Если у тебя дома три устройства, возможно, действительно незачем.

Если у тебя 30 VLAN, несколько серверов, Docker, Proxmox, камеры, точки доступа, принтеры, IP-телефония и пользователи, которые любят прописывать DNS вручную, ситуация меняется.

Собственный DNS даёт четыре вещи.

Контроль

Ты сам решаешь, куда отправлять DNS-запросы.

Можно использовать прямую рекурсию. Можно использовать Cloudflare, Google, Quad9 или другой resolver через DoH, DoT или DoQ. Technitium поддерживает такие варианты непосредственно.

Локальные имена

Можно сделать:

proxmox.lab.example

zabbix.lab.example

nas.lab.example

git.lab.example

И больше не вспоминать, какой именно адрес был у сервера три месяца назад.

Фильтрация

DNS-запросы можно фильтровать до того, как браузер установит соединение с рекламным или вредоносным доменом.

Technitium умеет автоматически обновлять block list URL и использовать их для блокировки рекламы и вредоносных доменов.

Диагностика

DNS-логи позволяют увидеть, что реально происходит в сети.

Какие домены запрашивает клиент. Какой сервер отвечает. Есть ли NXDOMAIN. Какие запросы внезапно пошли тысячами.

Иногда DNS-лог рассказывает о заражённом компьютере больше, чем пользователь.

3. Архитектура Technitium DNS Server

В простейшем варианте схема выглядит так:

Клиент спрашивает DNS.

Technitium сначала проверяет локальные данные и кеш. Если ответа нет, запрос уходит дальше по настроенной схеме.

Это может быть собственная рекурсия или forwarder.

4. Recursive DNS или Forwarder?

Здесь начинается интересная инженерная часть.

Есть два базовых подхода.

Вариант 1. Полная рекурсия

Technitium самостоятельно разрешает домен.

Условно:

client -> Technitium -> root -> TLD -> authoritative server.

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

Минус тоже очевиден: появляется больше ответственности за DNS-инфраструктуру.

Вариант 2. Forwarder

Technitium принимает запрос от клиента, а затем отправляет его, например, в Cloudflare или Quad9.

Причём транспорт может быть зашифрованным.

Technitium поддерживает DoH, DoT и DoQ в качестве транспорта для forwarders.

Для небольшой компании я часто выбрал бы именно этот вариант.

Он проще для эксплуатации и даёт понятную точку контроля.

5. DNS over HTTPS, DNS over TLS и DNS over QUIC

Здесь часто возникает маркетинговая каша.

DoH, DoT и DoQ не делают DNS «магически безопасным». Они шифруют транспорт между DNS-клиентом и DNS-сервисом.

Это разные вещи.

• DoT использует TLS.
• DoH передаёт DNS через HTTPS.
• DoQ использует QUIC.

Technitium умеет работать с этими протоколами и как клиент к forwarder, и как сервер для клиентов сети. DoH дополнительно поддерживает HTTP/1.1, HTTP/2 и HTTP/3.

Для инфраструктуры это интересно хотя бы потому, что можно централизованно отправлять DNS наружу через защищённый транспорт.

6. DNSSEC

DNSSEC нужен не для шифрования DNS.

Он решает другую задачу: позволяет проверять криптографическую подлинность DNS-ответов.

Technitium поддерживает DNSSEC validation для recursive resolver и forwarders, а также DNSSEC-подписанные зоны. Поддерживаются RSA, ECDSA и EdDSA.

Для корпоративной сети это особенно полезно там, где DNS имеет отношение к критичным сервисам.

Но DNSSEC нельзя включать по принципу «галочку поставил и забыл».

Сначала проверь цепочку доверия. Потом тестируй отказоустойчивость.

7. DNS-фильтрация и sinkhole

Одна из самых привлекательных функций Technitium для домашней сети и малого офиса — блокировка доменов.

Механика простая.

Клиент спрашивает DNS:

ads.example.net

Technitium сверяет домен с block list.

Если домен заблокирован, нормального разрешения не происходит.

Реклама не получает IP.

Technitium поддерживает несколько block list URL и умеет автоматически обновлять списки.

Есть и более продвинутые возможности.

Например, Advanced Blocking DNS App поддерживает REGEX-based block lists и разные списки для разных IP-адресов или подсетей.

Вот здесь Technitium начинает заметно отличаться от простого DNS-кеша.

8. Split Horizon DNS

Одна из действительно полезных функций для корпоративной сети.

Представь домен:

example.com

Снаружи:

www.example.com -> публичный IP.

Внутри:

www.example.com -> 10.10.10.20.

Это классический split horizon DNS.

Technitium позволяет реализовать такие сценарии через DNS Apps и локальные зоны. Официальный список возможностей прямо указывает поддержку Split Horizon и географических DNS-ответов через DNS Apps.

Это позволяет не городить странные правила на клиентах.

9. Conditional Forwarding

Если в инфраструктуре уже есть Active Directory, DNS Technitium не обязан заменять всё сразу.

Например:

*.corp.local -> Windows DNS.

Все остальные домены -> Technitium.

Получаем:

Это хороший миграционный сценарий.

Не надо в пятницу вечером выключать старый DNS и смотреть, что произойдёт.

10. Установка Technitium DNS Server на Linux

Официальный сайт предоставляет автоматический установщик для Linux и Raspberry Pi.

На момент публикации команда установки выглядит так:

curl -sSL https://download.technitium.com/dns/install.sh | sudo bash

После установки проверь сервис.

sudo systemctl status dns

Название unit стоит проверить на конкретной системе, если дистрибутив или способ установки отличаются.

Проверь, что DNS-порт слушается.

sudo ss -lntup | grep -E ':53|:5380'

Веб-консоль по умолчанию доступна на порту 5380. Официальная инструкция указывает localhost:5380 как первоначальную точку входа.

11. Практический пример №1: DNS для домашней сети

Допустим, у тебя:

• роутер MikroTik — 192.168.10.1;
• Technitium — 192.168.10.10;
• клиенты — 192.168.10.0/24.

На MikroTik раздаёшь DHCP-клиентам DNS 192.168.10.10.

В результате весь DNS-трафик сети проходит через Technitium.

Дальше включаешь block lists.

Получаешь централизованную DNS-фильтрацию для компьютеров, телефонов, телевизоров и IoT.

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

12. Практический пример №2: локальный DNS для Proxmox

Есть небольшой сервер:

• Proxmox;
• несколько VM;
• несколько LXC;
• Docker;
• NAS;
• Zabbix;
• Grafana.

Без локального DNS ты быстро начинаешь жить среди IP-адресов.

Создай локальную DNS-зону.

Например:

• pve01.lab.example;
• zabbix.lab.example;
• grafana.lab.example;
• nas.lab.example;
• docker01.lab.example.

Теперь мониторинг и администрирование используют имена.

IP меняется — меняешь одну DNS-запись.

А не двадцать конфигов.

13. Практический пример №3: Technitium + Active Directory

Здесь я бы не советовал сразу выкидывать Windows DNS.

AD любит свой DNS.

Лучше сделать conditional forwarding.

Technitium принимает DNS от клиентов.

Запросы к внутренней AD-зоне отправляет на Windows DNS.

Интернет-запросы разрешает сам или передаёт forwarder.

Получается архитектура:

Это намного безопаснее, чем устраивать DNS-революцию в рабочий день.

14. Практический пример №4: DNS-фильтр для VLAN

Представь сеть с VLAN:

• VLAN 10 — сотрудники;
• VLAN 20 — гости;
• VLAN 30 — IoT;
• VLAN 40 — серверы.

Technitium можно использовать как центральный DNS.

Для разных подсетей можно применять разные правила блокировки через DNS Apps.

Например, IoT получает более жёсткую фильтрацию.

Серверный VLAN получает минимальный набор ограничений.

Гостевая сеть получает отдельную политику.

Так DNS превращается из «службы перевода имён» в элемент сетевой политики.

15. Практический пример №5: два Technitium DNS в production

Один DNS-сервер — это не отказоустойчивость.

Это SPOF с хорошей веб-мордой.

Для production подними минимум два узла.

Например:

• dns01 — 10.10.10.53;
• dns02 — 10.10.10.54.

Клиенты получают оба адреса.

В Technitium есть встроенный clustering, который позволяет управлять несколькими DNS Server instances из одной административной консоли и синхронизировать общие настройки между узлами. Эта возможность появилась как крупная функция версии 14 и присутствует в актуальной ветке.

В версии 15 добавлена интеграция SSO через OpenID Connect, включая автоматическое provisioning пользователей и привязку пользователей к группам для RBAC.

16. Technitium DNS Server и Docker

Если инфраструктура уже живёт в Docker, Technitium можно не устанавливать непосредственно на host.

Официальный Docker image доступен как:

docker pull technitium/dns-server:latest

Официальный сайт также предлагает пример docker-compose.yml.

Но здесь есть один нюанс.

DNS — это инфраструктурный сервис. Если Docker host умер, DNS тоже умер.

Поэтому я бы не ставил единственный production DNS в контейнер на том же сервере, где крутится половина бизнеса.

Для лаборатории — отлично.

Для production — минимум два независимых узла.

17. Системные требования

Technitium довольно нетребователен к железу.

Официальный проект заявляет высокую производительность и приводит нагрузочное тестирование более 100 000 DNS-запросов в секунду на Intel i7-8700 по Gigabit Ethernet. Это не означает, что домашнему серверу нужен i7. Наоборот, для обычной сети такая производительность будет избыточной.

Компонент	Рекомендация	Комментарий
CPU	1-2 современных ядра	Для небольшой сети более чем достаточно
RAM	512 MB — 1 GB+	Зависит от кеша, логов и DNS Apps
Диск	SSD	Особенно полезен при persistent cache и логировании
ОС	Linux / Windows / macOS	Поддерживается также Raspberry Pi
Runtime	.NET 10 для текущей ветки	Проверяй требования конкретного релиза
Docker	Да	Есть официальный образ

На момент публикации актуальна версия 15.4 и .NET 10. Перед установкой проверь свежие релизы.

18. Какие порты нужны Technitium

Порт	Протокол	Назначение
53	UDP/TCP	Обычный DNS
5380	TCP	Web Console по умолчанию
853	TCP	DNS-over-TLS, если используется стандартная конфигурация
443	TCP	DNS-over-HTTPS при соответствующей настройке
443	UDP	DNS-over-QUIC при соответствующей настройке

Не открывай административную панель наружу просто потому, что «она же с паролем».

Web Console должна быть доступна только администраторам.

19. Безопасность Technitium DNS

DNS-сервер обычно находится в очень интересной позиции.

Его видят практически все клиенты.

Поэтому компрометация DNS превращается в очень неприятную историю.

Firewall

Разреши DNS только от нужных сетей.

sudo ufw allow from 10.10.0.0/16 to any port 53 proto udp
sudo ufw allow from 10.10.0.0/16 to any port 53 proto tcp

Административный порт ограничь ещё сильнее.

sudo ufw allow from 10.10.10.0/24 to any port 5380 proto tcp

Если Technitium используется только внутри сети, DNS-порты не должны быть доступны всему интернету.

SSH

Если сервер управляется по SSH, используй отдельного администратора.

Отключи root login.

PermitRootLogin no
PasswordAuthentication no

И используй SSH-ключи.

Web Console

Встроенная панель имеет RBAC, API tokens и TOTP-based 2FA. Это хороший набор возможностей для инфраструктурного сервиса.

Но наличие 2FA не отменяет firewall.

20. Первый запуск: что изменить сразу

После установки не оставляй дефолтную авторизацию.

Официальная инструкция указывает первоначальные данные admin/admin и прямо предупреждает сменить пароль для отключения автоматического входа.

Сразу сделай:

• измени пароль администратора;
• включи 2FA;
• ограничь доступ к Web Console;
• настрой DNS upstream или рекурсию;
• проверь DNSSEC;
• настрой резервное копирование конфигурации;
• включи мониторинг;
• проверь DNS с нескольких VLAN.

21. Проверка DNS после установки

Первый тест должен быть максимально простой.

dig @192.168.10.10 example.com

Проверь, что получен корректный ответ.

Потом проверь кеш.

dig @192.168.10.10 example.com
dig @192.168.10.10 example.com

Сравни время ответа.

Для диагностики конкретного типа записи:

dig @192.168.10.10 example.com A
dig @192.168.10.10 example.com AAAA
dig @192.168.10.10 example.com MX
dig @192.168.10.10 example.com TXT

Для проверки DNSSEC:

dig @192.168.10.10 example.com +dnssec

Не ограничивайся тестом «браузер открыл сайт».

Браузер может использовать собственный DoH и вообще обходить твой DNS.

22. Troubleshooting: DNS не работает

Ошибка: ping до DNS есть, DNS не отвечает

Причина: firewall, сервис не слушает 53 порт или клиент отправляет запрос не туда.

Проверь:

sudo ss -lntup | grep ':53'

Потом:

dig @10.10.10.53 example.com

Ошибка: UDP работает, TCP нет

Причина: firewall или неправильная публикация DNS.

DNS использует не только UDP.

TCP может потребоваться для больших ответов, DNSSEC и других сценариев.

Проверь:

dig @10.10.10.53 example.com +tcp

Ошибка: Technitium работает, но клиенты не используют его

Причина: DHCP продолжает выдавать старый DNS.

Проверь настройки DHCP.

На Linux:

resolvectl status

На Windows:

Get-DnsClientServerAddress

Не забудь про браузерный DoH.

Если Chrome, Firefox или Edge отправляет DNS напрямую через HTTPS, твой локальный DNS может вообще не увидеть часть запросов.

Ошибка: локальные имена не разрешаются

Причина: зона не создана или запрос уходит в интернетовый resolver.

Проверь:

dig @10.10.10.53 server01.lab.example

Если Technitium не отвечает локальной записью, смотри настройки зоны и порядок обработки DNS Apps.

Ошибка: после включения block list перестал работать сайт

Причина: заблокирован домен, который нужен приложению.

Не отключай всю фильтрацию.

Найди конкретный домен в query log.

Добавь исключение.

После этого повтори запрос.

23. Где Technitium реально выигрывает

Technitium особенно интересен там, где обычного DNS-фильтра уже мало.

• Домашняя сеть с большим количеством IoT.
• Лаборатория с Proxmox и Docker.
• Малый офис.
• Сеть с несколькими VLAN.
• Инфраструктура с локальными DNS-зонами.
• Компания, где нужен authoritative DNS.
• Сценарии с DNSSEC.
• Инфраструктура, где нужен DoH/DoT/DoQ.
• Среда, где нужен API и автоматизация.

24. Где Technitium может быть избыточен

Если тебе нужно только заблокировать рекламу дома, Technitium может оказаться мощнее, чем требуется.

AdGuard Home проще для многих домашних пользователей.

Pi-hole тоже может быть проще для конкретного сценария.

Если у тебя уже есть Windows Server с AD DNS и инфраструктура работает годами, не надо ставить Technitium просто потому, что он красивый.

Новая система должна решать проблему.

А не создавать новую.

25. Technitium DNS Server vs Pi-hole

Возможность	Technitium	Pi-hole
DNS filtering	Да	Да
Recursive DNS	Да	Через дополнительные компоненты
Authoritative DNS	Да	Не основной сценарий
DNSSEC	Да	Зависит от resolver
DoH	Да	Через дополнительные компоненты/настройки
DoT	Да	Не основная функция
DoQ	Да	Не основной сценарий
Clustering	Да	Требует дополнительных решений
API	Да	Да
DHCP	Да	Да

Pi-hole остаётся отличным выбором, если главная задача — DNS filtering.

Technitium интереснее, если DNS должен стать полноценным инфраструктурным сервисом.

26. Technitium DNS Server vs AdGuard Home

AdGuard Home очень удобен.

Его сильная сторона — простая эксплуатация и отличный UX для DNS-фильтрации.

Technitium делает акцент на более глубокой DNS-функциональности.

Здесь появляются authoritative zones, AXFR/IXFR, DNSSEC signed zones, advanced forwarding, DNS Apps, clustering и большое количество современных DNS-возможностей.

Поэтому вопрос не «что лучше».

Вопрос «что именно мне нужно от DNS».

27. Technitium DNS Server vs DNS на MikroTik

Если у тебя MikroTik, возникает логичный вопрос: зачем вообще отдельный DNS?

MikroTik отлично умеет быть DNS cache для небольших сетей.

Но Technitium даёт значительно больше возможностей для специализированного DNS.

Особенно если нужны:

• сложные локальные зоны;
• DNSSEC;
• authoritative DNS;
• DoH/DoT/DoQ;
• DNS Apps;
• расширенная фильтрация;
• подробная DNS-аналитика;
• clustering;
• API.

Я бы не заменял DNS на MikroTik автоматически.

Можно оставить MikroTik DHCP и маршрутизацию, а DNS вынести на Technitium.

Это чистое разделение ответственности.

28. DNS Apps — одна из самых интересных возможностей

DNS Apps позволяют расширять поведение DNS-сервера.

Это уже не просто настройки вида «A-запись -> IP».

Через приложения можно реализовывать дополнительные сценарии обработки DNS-запросов.

Официальный список функций указывает поддержку кастомных DNS Apps, которые могут напрямую обрабатывать DNS-запросы и формировать ответы по заданной бизнес-логике.

Для инженера это очень интересный механизм.

DNS превращается в programmable control plane.

Но здесь я бы держал себя за руки.

Если задача решается обычной DNS-записью, не надо писать приложение на 700 строк.

29. DHCP в Technitium

Technitium имеет встроенный DHCP Server, который может работать с несколькими сетями.

Это позволяет построить достаточно автономную инфраструктуру.

Но я бы разделял DNS и DHCP там, где уже есть нормальный маршрутизатор.

Например:

MikroTik -> DHCP

Technitium -> DNS

Zabbix -> monitoring

Grafana -> visualization

Так проще искать проблему.

Одна служба — одна ответственность.

30. Мониторинг Technitium

DNS должен мониториться.

Минимальный набор:

• availability;
• DNS response time;
• NXDOMAIN rate;
• SERVFAIL rate;
• CPU;
• RAM;
• disk;
• query rate;
• ошибки upstream.

Для Zabbix можно использовать HTTP API или собственные проверки.

У Technitium есть встроенный HTTP API, причём сама Web Console использует этот API для выполнения операций управления.

Это хорошая основа для автоматизации.

31. Резервное копирование

Не надо считать DNS настолько простым, что его можно восстановить «за пять минут».

Да, сам DNS поднять можно быстро.

А вот восстановить все зоны, политики, forwarding, DNS Apps, ACL и остальные настройки без нормального backup уже веселее.

Бэкапируй:

• конфигурацию Technitium;
• локальные DNS-зоны;
• настройки DNS Apps;
• политики фильтрации;
• сертификаты;
• секреты и API tokens в защищённом хранилище.

Храни минимум одну копию вне самого DNS-сервера.

Для production желательно иметь две независимые DNS-ноды плюс резервную копию конфигурации.

32. Обновление Technitium

Перед обновлением:

• сделай backup;
• проверь свободное место;
• проверь текущую версию;
• прочитай changelog;
• проверь совместимость .NET runtime;
• убедись, что есть второй DNS.

В версии 15 произошёл переход на .NET 10, а Linux- и Windows-установки получили дополнительные hardening-механизмы и запуск сервиса без root. При ручной установке или старом runtime это нужно учитывать при обновлении.

Обновляй сначала вторичную ноду.

Проверь.

Потом обновляй первую.

Не обновляй единственный DNS в рабочее время в пятницу.

33. Типичная production-архитектура

Для небольшой компании я бы смотрел примерно на такую схему:

Клиенты получают два DNS-адреса.

Обе ноды имеют одинаковые локальные зоны и политики.

Наружу DNS уходит через выбранные encrypted forwarders либо через recursive resolution.

Мониторинг следит за обеими нодами.

34. Что меня удивило в Technitium

Самое интересное здесь не фильтрация рекламы.

Этим сегодня никого не удивишь.

Интересно другое: Technitium пытается закрыть почти весь жизненный цикл DNS в одном продукте.

Recursive DNS.

Authoritative DNS.

DNSSEC.

Encrypted DNS.

Clustering.

DNS Apps.

API.

DHCP.

RBAC.

OIDC.

Это уже не «Pi-hole с несколькими дополнительными галочками».

35. Когда я бы выбрал Technitium

Я бы поставил Technitium, если мне нужно:

• централизовать DNS нескольких VLAN;
• создать полноценные локальные зоны;
• иметь recursive и authoritative DNS в одном продукте;
• использовать DNSSEC;
• шифровать DNS upstream;
• фильтровать рекламу и malware;
• управлять несколькими DNS-узлами;
• автоматизировать управление через API;
• получить расширяемость через DNS Apps.

Для домашнего DNS с двумя ноутбуками я бы не усложнял жизнь.

Для лаборатории, homelab и инфраструктуры малого бизнеса Technitium выглядит гораздо интереснее.

36. Когда я бы его не выбирал

Если нужна исключительно простая блокировка рекламы, AdGuard Home может быть удобнее.

Если инфраструктура полностью завязана на Active Directory, Windows DNS остаётся естественным выбором для AD-зоны.

Если DNS должен жить прямо на маршрутизаторе и требований больше нет, MikroTik DNS может быть достаточен.

Главное правило простое.

Не ставь отдельный сервис только потому, что он умеет больше.

Лишняя функциональность тоже имеет цену.

37. Частые ошибки при внедрении

Ошибка 1. Один DNS на всю компанию

Один сервер — один SPOF.

Ошибка 2. DNS открыт в интернет

Открытый recursive resolver — плохая идея.

Ты не хочешь случайно превратить сервер в инструмент для DNS amplification.

Ошибка 3. Панель управления доступна всем VLAN

DNS нужен пользователям.

Админка пользователям не нужна.

Ошибка 4. Не проверяется браузерный DoH

Часть DNS-запросов может обходить локальный resolver.

Ошибка 5. Фильтры включили и забыли

Block list иногда ломает приложения.

Поэтому нужны логи и понятный процесс исключений.

38. Как понять, что Technitium тебе подходит

Задай себе семь вопросов.

• Мне нужен только ad-block или полноценный DNS?
• Нужны ли локальные DNS-зоны?
• Есть ли несколько VLAN?
• Нужен ли DNSSEC?
• Нужен ли DoH/DoT/DoQ?
• Нужен ли authoritative DNS?
• Нужна ли отказоустойчивость?

Если большинство ответов «да», Technitium стоит попробовать.

39. FAQ

Technitium DNS Server бесплатный?

Да. Это open source проект под GNU GPLv3. Исходный код опубликован на GitHub.

Можно ли установить Technitium DNS Server на Ubuntu?

Да. Официальный проект предоставляет автоматический установщик для Linux. Также доступны portable-архивы.

Можно ли запустить Technitium в Docker?

Да. Существует официальный Docker image technitium/dns-server.

Technitium умеет блокировать рекламу?

Да. Можно подключать block list URL, которые автоматически обновляются, и блокировать рекламу и malware на уровне DNS.

Есть ли в Technitium DNSSEC?

Да. Поддерживаются DNSSEC validation и DNSSEC signed zones, включая RSA, ECDSA и EdDSA.

Есть ли DoH, DoT и DoQ?

Да. Technitium поддерживает DNS-over-HTTPS, DNS-over-TLS и DNS-over-QUIC.

Можно ли использовать Technitium вместе с Active Directory?

Да. Для этого удобно использовать conditional forwarding и оставить AD DNS ответственным за внутреннюю AD-зону.

Technitium может заменить Pi-hole?

Да, если задача шире обычной DNS-фильтрации. Technitium предоставляет filtering плюс recursive, authoritative DNS, DNSSEC, encrypted DNS, clustering и другие инфраструктурные возможности.

Technitium может заменить DNS на MikroTik?

Технически да. Но не всегда это нужно. MikroTik может продолжать выполнять DHCP и маршрутизацию, а Technitium можно выделить в отдельный DNS-сервис.

40. Итоговый диагноз

Technitium DNS Server — один из тех проектов, которые сначала выглядят как «ещё один DNS», а после знакомства с возможностями становится понятно, что перед тобой гораздо более серьёзный инструмент.

Он подходит для homelab, малого бизнеса и вполне серьёзных инфраструктурных сценариев. При этом проект остаётся open source, кроссплатформенным и доступным для запуска на Linux, Windows, macOS, Raspberry Pi или Docker.

Главная сильная сторона Technitium — не какая-то одна функция.

Сильная сторона в том, что recursive DNS, authoritative DNS, DNSSEC, encrypted DNS, filtering, локальные зоны, API, clustering и DNS Apps собраны в одной системе.

Для домашнего пользователя это может быть избыточно.

Для сетевого инженера это уже совсем другой разговор.

Особенно если DNS должен стать не «сервером, который просто отвечает на запросы», а нормальной частью архитектуры сети.

И вот здесь Technitium становится действительно интересным.

Я бы начал с одной VM.

Подключил один VLAN.

Проверил кеширование, фильтрацию, локальные зоны и encrypted upstream.

Потом добавил вторую ноду.

А уже после этого решал, нужен ли clustering, DNS Apps и остальная тяжёлая артиллерия.

Потому что хороший DNS должен быть скучным.

Очень скучным.

Он должен просто отвечать.

Быстро.

Всегда.

А если инженер вспоминает о нём только потому, что в Zabbix загорелся красный триггер, значит DNS сделан правильно.

Если не заработало — пиши, разберёмся.

Источники и актуальность

Основной источник для обзора — официальный сайт Technitium DNS Server и документация проекта. На момент публикации официальный сайт указывает версию 15.4.

Версия 15 была выпущена 25 апреля 2026 года. В ней появился OIDC SSO, выполнен переход на .NET 10, а установщики для Windows и Linux получили дополнительные механизмы hardening.

Исходный код Technitium DNS Server распространяется под GPLv3 и опубликован на GitHub