Unbound или Technitium DNS: что выгоднее и когда

MAATRIX

Когда встаёт вопрос «поставить свой DNS-резолвер», рано или поздно натыкаешься на два имени — Unbound и Technitium. Оба решают задачу «не доверять DNS-запросы чужому серверу», но это два разных по философии инструмента: один — минималистичный демон без интерфейса, другой — полноценная DNS-платформа с веб-панелью. Разберём честно, по каким критериям выбирать и когда один явно выгоднее другого, а когда разница не принципиальна.

Что это за инструменты и в чём принципиальная разница

Unbound — рекурсивный кеширующий резолвер от NLnet Labs, написан на C, работает как один процесс без графического интерфейса вообще. Вся настройка — текстовые конфиги в /etc/unbound/unbound.conf.d/, управление — через unbound-control из консоли. Задача у него одна: сам ходить к корневым серверам DNS, проверять DNSSEC-подписи и отдавать результат тому, кто спросил. Никаких зон, никакой блокировки рекламы, никакого DoH-сервера из коробки — это осознанно узкий инструмент.

Technitium DNS Server — написан на .NET, поднимается как systemd-сервис с веб-панелью на порту 5380. Внутри — рекурсивный резолвер (сравнимый по сути с Unbound), плюс авторитативный сервер собственных зон (как BIND9 или PowerDNS), плюс блокировка по спискам (как Pi-hole или AdGuard Home), плюс DoH/DoT/DoQ-сервер для шифрованных запросов клиентов. По факту это четыре разных сервиса, слитых в один процесс с единым UI.

Разница не в том, «какой лучше», а в том, что вы вообще хотите получить: узкоспециализированный резолвер, который делает одну вещь предельно надёжно, или комбайн, закрывающий сразу несколько ролей без необходимости разворачивать отдельные демоны и синхронизировать их конфиги. Если у вас уже стоит Pi-hole или AdGuard Home и не хватает только доверенного резолвинга — это прямой сценарий под установку Unbound на VPS. Если вам нужны свои DNS-зоны для домена плюс блокировка плюс шифрование — присмотритесь к пошаговой установке Technitium на Ubuntu 24.04.

Ресурсы: сколько нужно VPS под каждый

Unbound — самый лёгкий из всех перечисленных здесь инструментов. Написан на C, не тащит рантайм-зависимости, стартует за доли секунды. Для личного использования и небольшой семьи хватает 512 МБ RAM с настройками кеша по умолчанию — фактически это самый дешёвый тариф VPS, который вообще существует. Даже при увеличенном кеше (msg-cache-size, rrset-cache-size по 128-256 МБ) итоговое потребление редко превышает 300-400 МБ.

Technitium требует .NET 8 runtime, что сразу поднимает планку: минимум 512 МБ-1 ГБ RAM под сам процесс плюс место под .NET-рантайм на диске (около 150-200 МБ), плюс отдельные мегабайты под базы блок-листов, если вы подключаете крупные источники вроде oisd.nl с сотнями тысяч доменов. Для дома и небольшой команды разработчики рекомендуют 1 vCPU/1 ГБ, для сотен тысяч запросов в сутки — 2 vCPU/2 ГБ.

На практике разница в стоимости хостинга редко критична — оба укладываются в самый дешёвый тариф VPS. Разница ощутима на слабом железе (старые ARM-платы, VPS с 256-512 МБ RAM без свопа) — там Unbound запустится и будет работать стабильно, а Technitium может начать упираться в память при большом блок-листе. Если сервер и так минимальный и делит ресурсы с другими сервисами, узкий Unbound — более безопасный выбор по памяти.

Функциональность: сравнение по задачам

Здесь разница принципиальная, и именно она чаще всего решает выбор:

Unbound не умеет ничего, кроме резолвинга — и это честное ограничение, а не недоработка. Если вам нужна блокировка рекламы, его ставят рядом с Pi-hole или AdGuard Home как upstream-резолвер именно потому, что сам он фильтрацией не занимается. Technitium закрывает все эти задачи одним процессом, но платит за это сложностью: больше поверхность атаки (веб-панель, REST API, несколько протоколов слушают порты одновременно), больше параметров, которые можно неправильно настроить.

Производительность и надёжность в проде

Точных цифр по скорости резолвинга «Unbound на Х% быстрее Technitium» вы нигде не найдёте честных — оба используют схожие алгоритмы кеширования и рекурсии, а реальная задержка зависит куда сильнее от сети до корневых серверов, качества канала VPS и загруженности CPU в моменте, чем от самого движка резолвера. Не доверяйте бенчмаркам без указания методологии и железа — на вашем сервере цифры почти наверняка будут другими.

Что можно сказать предметно: Unbound как компилируемый C-демон стабильно держит нагрузку с предсказуемым потреблением памяти — она растёт вместе с размером кеша (msg-cache-size + rrset-cache-size) и плато, дальше не увеличивается. У .NET-приложений, к которым относится Technitium, память управляется сборщиком мусора — потребление колеблется рывками, что на VPS с жёстким лимитом RAM (без свопа) иногда приводит к OOM-килу процесса под пиковой нагрузкой, если тариф взят впритык. Проверить фактическое потребление на своём сервере проще всего простым мониторингом:

# Unbound
systemctl status unbound
ps -o rss,vsz,cmd -C unbound

# Technitium
systemctl status dns
ps -o rss,vsz,cmd -C DnsServerApp

Из практики эксплуатации: Unbound требует внимания реже — если конфиг синтаксически верен (unbound-checkconf перед каждым рестартом) и root.key актуален, сервис работает месяцами без вмешательства. Technitium требует чуть больше присмотра именно из-за большего количества движущихся частей — обновления .NET, ротация логов при включённом файловом логировании, размер базы блок-листов при частых Force Update. Ничего критичного, но это реальная разница в объёме операционной рутины.

Когда выгоднее Unbound

Unbound — правильный выбор, если вы:

• уже используете Pi-hole или AdGuard Home и хотите заменить публичный upstream (8.8.8.8, 1.1.1.1) на собственный резолвинг без посредников;
• держите VPS с жёстким лимитом RAM (256-512 МБ) и не хотите тратить память на рантайм и веб-панель;
• цените минимальную поверхность атаки — Unbound не открывает веб-интерфейс, не тащит REST API, нечего ломать снаружи, кроме самого DNS-протокола;
• хотите предсказуемое поведение под нагрузкой без скачков GC-паузы .NET;
• вам не нужны свои DNS-зоны и шифрованный DoH/DoT-сервер для клиентов — только чистый резолвинг с DNSSEC.

Это классический выбор для домашней сети или небольшой команды, где DNS — фоновая инфраструктура, а не отдельный продукт. Сколько именно памяти закладывать под конкретный сценарий, разобрано отдельно в статье про требования Unbound к RAM.

Когда выгоднее Technitium (и когда — оба вместе)

Technitium выгоднее, если вам нужно закрыть сразу несколько ролей без разворачивания нескольких сервисов:

• держать авторитативные зоны для своих доменов (замена BIND9/PowerDNS) — с UI, а не ручной правкой zone-файлов;
• одновременно фильтровать рекламу/трекеры и резолвить остальное — без связки «блокировщик + отдельный резолвер»;
• отдавать DoH/DoT клиентам наружу — например, для мобильных устройств вне дома, которым нужен зашифрованный DNS до вашего сервера;
• администрировать DNS без постоянного SSH-доступа — через веб-панель и REST API, что удобно, если DNS обслуживает не только вас;
• получать метрики и топ-домены из коробки без сторонних инструментов вроде Grafana поверх экспортёров.

Отдельный рабочий сценарий — использовать оба вместе, а не выбирать один. Technitium умеет работать как форвардер к upstream-резолверу вместо собственной рекурсии — если вы уже доверяете DNSSEC-валидации Unbound и хотите добавить к нему зоны/блокировку/DoH, можно поднять Technitium на том же или соседнем сервере и указать Unbound как upstream в Settings → DNS → Recursion → Forwarders, прописав 127.0.0.1:5335. Так вы получаете строгую DNSSEC-валидацию от Unbound и весь остальной функционал от Technitium одним запросом. Ставить их наоборот (Unbound как форвардер к Technitium) смысла не имеет — Unbound не форвардер по природе, он либо резолвит сам с нуля, либо использует upstream без собственной рекурсии, что убивает смысл его ставить вообще.

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