Сколько RAM нужно для Technitium DNS

MAATRIX

Technitium DNS Server выделяется среди DNS-решений тем, что закрывает сразу три задачи одним сервисом: рекурсивный резолвер с блокировкой рекламы, authoritative-сервер для собственных зон и площадку для DoH/DoT/DoQ — и всё это через полноценную веб-панель, без ручной правки конфигов. За такую универсальность платят памятью: сервис написан на C#/.NET, и это уже даёт другой стартовый профиль потребления, чем у компактных Go- или C-бинарников вроде AdGuard Home или PowerDNS. Официальный сайт называет скромные системные требования, но они рассчитаны на минимальный сценарий «поставил и забыл» — как только подключаются зоны, DNSSEC-подпись, приложения (apps) и шифрованные протоколы, цифры сдвигаются заметно. Разберём, куда уходит память у Technitium и сколько закладывать под разные роли сервера.

Сколько RAM нужно Technitium DNS: короткий ответ

Ориентир по сценариям использования — не жёсткая граница, а рабочий диапазон, в который реально укладывается большинство инсталляций:

Официально Technitium указывает минимальные требования порядка 512 МБ ОЗУ и одного ядра CPU — это правда работает, если сервер выполняет одну простую роль. Но так как процесс живёт под .NET-рантаймом, у него выше базовый footprint по сравнению с DNS-серверами на компилируемых языках без сборщика мусора — сама виртуальная машина .NET, JIT-компиляция и управляемая куча съедают часть памяти ещё до первого DNS-запроса.

Из чего складывается потребление памяти

Рантайм .NET. Technitium распространяется как self-contained сборка (рантайм .NET упакован внутри дистрибутива), так отдельно ставить .NET не нужно, но сама память под управляемую кучу и сборщик мусора всё равно расходуется — это тот компонент, которого нет у AdGuard Home (Go) или PowerDNS (C++). На практике это добавляет условно 40-80 МБ базового расхода поверх «полезной» нагрузки, и это стоит учитывать при подборе тарифа.

Зоны и типы записей. Если Technitium используется как authoritative-сервер для собственных доменов (primary-зоны), каждая зона со всеми записями хранится в памяти процесса для быстрого ответа. Для небольшого числа доменов это несущественно, но при десятках зон с большим числом записей (например, зона с сотнями поддоменов под balancing или CDN) объём заметно растёт. Посмотреть список зон и их размер можно в веб-панели на вкладке Zones, либо через API:

curl -s "http://127.0.0.1:5380/api/zones/list?token=YOUR_TOKEN" | jq '.response.zones | length'

DNSSEC-подпись. Если вы подписываете свои authoritative-зоны (DNSSEC signing, не просто валидация чужих ответов), Technitium держит в памяти ключи (ZSK/KSK) и подписанные RRSIG-записи для каждой зоны — это ощутимо тяжелее, чем неподписанная зона того же размера. Валидация DNSSEC у входящих ответов (когда сервер работает как резолвер) намного легче, чем подпись собственных зон.

Блок-листы и Advanced Blocking. Как и у большинства DNS-фильтров, списки блокировки хранятся в памяти для быстрого поиска по домену. Базовое приложение «Advanced Blocking» из App Store умеет группы блокировки по сетям и расписаниям, что удобно для смешанной инфраструктуры (дом + офис на одном сервере), но требует памяти под индексы групп сверх самих списков.

DNS Apps (плагины). У Technitium есть встроенный App Store: Query Logs (SQLite), Split Horizon, Failover & Load Balancing App и другие. Каждое включённое приложение — это отдельная загруженная сборка в памяти процесса. Ставьте только то, что реально используете — «на всякий случай» установленные и включённые приложения тихо съедают память постоянно, а не только во время работы.

DoH/DoT/DoQ и кэш резолвера. Как и у любого DNS-сервера с шифрованными протоколами, каждое активное TLS/QUIC-соединение держит контекст в памяти. Подробнее о том, зачем вообще нужен DNS-over-HTTPS и как он связан с доступом к нейросетям и сервисам за пределами страны, разобрано в статье DNS-over-HTTPS и доступ к ИИ.

Что происходит при нехватке памяти

На VPS с 512 МБ без свопа, где включили DNSSEC-подпись сразу для нескольких зон плюс DoH для домашней сети, типичный сценарий такой: под вечернюю нагрузку память заполняется, .NET garbage collector начинает работать агрессивнее (чаще запускается полная сборка мусора), ответы резолвера подтормаживают ещё до фактического OOM — это специфика управляемой среды, у компилируемых DNS-серверов такой промежуточной стадии обычно нет, там деградация более резкая. Если памяти не хватает совсем, ядро Linux завершает процесс:

dmesg | grep -i "killed process"
# Out of memory: Killed process 5678 (DnsServerApp)

После такого убийства резолвинг останавливается для всех клиентов, у которых Technitium прописан единственным DNS-сервером — не только зоны с DNSSEC перестают отвечать, а вообще любой запрос. Второй симптом при нехватке ОЗУ — не сам OOM, а свопинг: сервис продолжает работать, но веб-панель и API отвечают медленно, а TLS-хендшейки для DoH/DoT растягиваются на сотни миллисекунд вместо десятков. Как правильно рассчитать своп под такие пики, разобрано в статье правильный размер swap для VPS — для DNS-сервиса своп страхует вечерний пик, но не заменяет достаточный объём RAM на постоянной основе.

Как снизить потребление RAM

Если тариф ограничен по памяти, есть рабочие способы уменьшить расход без отказа от нужных функций.

Отключить неиспользуемые приложения. В веб-панели: Apps → отключить (Disable) всё, что не задействовано прямо сейчас, а не просто «может пригодиться». Каждое включённое приложение держит собственную память постоянно.

Ограничить размер кэша резолвера. В Settings → Cache можно задать Maximum Entries — по умолчанию значение рассчитано на активный публичный резолвер, для домашней сети или малого офиса его стоит уменьшить.

Не подписывать зоны DNSSEC без необходимости. Если authoritative-зона используется только внутри своей инфраструктуры (не публикуется как авторитетный источник для внешних резолверов), подпись DNSSEC часто избыточна и добавляет постоянный расход памяти без практической пользы.

Сократить журналирование запросов. Приложение Query Logs (SQLite) пишет каждый запрос — на активном сервере база и связанный с ней кэш в памяти растут быстро. В настройках приложения ограничьте срок хранения логов или отключите его вовсе, если детальная аналитика не нужна.

Пересмотреть блок-листы. Один качественный список эффективнее нескольких пересекающихся. Проверить количество активных правил:

curl -s "http://127.0.0.1:5380/api/settings/get?token=YOUR_TOKEN" | jq '.response.blockListUrls | length'

Проверить фактическое потребление до и после изменений:

free -h
systemctl status dns.service
ps aux | grep DnsServerApp

Technitium против AdGuard Home и PowerDNS: разница в памяти

Три сервиса решают частично пересекающиеся задачи, но по-разному устроены изнутри, и это прямо влияет на requirements по RAM.

Если задача — только блокировка рекламы для дома, разница в памяти между Technitium и AdGuard Home на практике невелика, и выбор скорее про интерфейс и набор функций. Но если нужен именно authoritative-сервер для собственных доменов с DNSSEC, Technitium конкурирует уже с PowerDNS — и там разница в базовом потреблении памяти между .NET и C++ более заметна на слабых тарифах.

Установка и запуск на VPS: практическая конфигурация

Официальный установочный скрипт для Linux:

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

Или через Docker Compose — удобнее для VPS с точки зрения изоляции и переноса конфигурации между серверами:

services:
  technitium-dns:
    container_name: technitium-dns
    image: technitium/dns-server:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "5380:5380/tcp"   # веб-панель
      - "853:853/tcp"     # DNS-over-TLS
      - "443:443/tcp"     # DNS-over-HTTPS
    environment:
      - DNS_SERVER_DOMAIN=dns.example.com
    volumes:
      - "./config:/etc/dns"
    restart: unless-stopped

Как и с любым публичным DNS-резолвером, 53 порт нельзя открывать в интернет без ограничений — незащищённый рекурсивный резолвер быстро становится участником DNS-амплификации в чужих DDoS-атаках, и хостинг вправе отреагировать на такой трафик жалобой или блокировкой. Если Technitium используется как рекурсивный резолвер или блокировщик рекламы для своих устройств (а не как публичный authoritative-сервер для чужих доменов), правильная схема — держать его доступным только через приватную сеть: клиенты подключаются по WireGuard и получают внутренний IP сервера как DNS. Настройка туннеля разобрана в статье WireGuard на Ubuntu 24.04. Authoritative-зоны, которые должны отвечать публично (это их прямое назначение), наоборот, держат 53 порт открытым — но тогда стоит закладывать больше памяти на всякий случай, потому что сервер становится видимым и получает больше случайного трафика, чем приватный резолвер.

Для тарифа с 512 МБ - 1 ГБ RAM и 1 vCPU обычно достаточно под резолвер или пару зон без DNSSEC. Если план включает подпись зон, несколько приложений и DoH/DoT одновременно — комфортнее стартовать сразу с 2 ГБ, чтобы не упираться в память при первом же всплеске трафика. Если на том же сервере планируется что-то ещё (VPN, панель мониторинга, файлохранилище), закладывайте память отдельно под каждый сервис — общие признаки нехватки RAM и как их поймать заранее разобраны в статье что делать при нехватке RAM.

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