Сколько RAM нужно для Unbound

MAATRIX

Unbound — это рекурсивный DNS-резолвер: вместо того чтобы спрашивать ответ у DNS-серверов Google или Cloudflare, он сам идёт по цепочке от корневых серверов до авторитетного NS домена и проверяет подпись DNSSEC на каждом шаге. Это радикально другая модель памяти, чем у форвардера вроде dnsmasq или publicной резолвинга через 8.8.8.8 — и когда Unbound ставят рядом с Pi-hole или AdGuard Home как upstream-резолвер, первый вопрос — сколько добавить RAM к уже занятой блокировщиком памяти. Разберём, из чего складывается расход и какие цифры реальны для разных сценариев.

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

Сам процесс unbound в покое, сразу после старта с настройками по умолчанию, занимает 15-25 МБ. Это заметно легче, чем BIND (полноценный DNS-сервер общего назначения) — Unbound спроектирован именно как узкоспециализированный рекурсор и валидатор, без лишнего функционала авторитетного сервера. Дальше память растёт почти линейно от размера кэша, который вы задаёте сами через msg-cache-size и rrset-cache-size, а не от количества клиентов напрямую.

Практический ориентир:

Официальная документация Unbound называет минимумом систему с 4 МБ свободной памяти под сам процесс — и технически он там стартует. Но это цифра для встраиваемых систем, а не для практичной конфигурации с адекватным кэшем и DNSSEC. Дальше — откуда реально берётся расход.

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

У Unbound память расходуется предсказуемо, потому что почти вся конфигурация — это явные лимиты в unbound.conf, а не «магия» как у некоторых демонов.

msg-cache и rrset-cache. Это два главных потребителя. msg-cache-size хранит закэшированные ответы целиком (запрос → ответ), rrset-cache-size — отдельные записи ресурсов (A, AAAA, MX и т.д.), которые Unbound переиспользует между разными ответами. По умолчанию оба выставлены в 4 МБ — крошечно для чего-либо серьёзнее одного ноутбука. Правило из документации: держите rrset-cache-size примерно вдвое больше msg-cache-size, они работают в паре.

DNSSEC-валидация. Каждый ответ, который проходит через модуль validator, требует держать в памяти цепочку доверия (chain of trust) — DS- и DNSKEY-записи от корня до листового домена — пока идёт проверка подписи. Это не постоянный расход (цепочка не хранится вечно для каждого домена), но валидация ощутимо повышает пиковое потребление CPU и кратковременные всплески памяти по сравнению с резолвером без DNSSEC.

num-threads и per-thread память. Unbound может работать в несколько потоков (num-threads в конфиге), и по умолчанию — по историческим причинам конфигурации ядра — каждый поток получает свою долю от заданных лимитов кэша, если не выставлен msg-cache-slabs/rrset-cache-slabs кратно числу потоков. На однопроцессорной VPS с 1 vCPU разумно держать num-threads: 1 — прироста от параллелизма всё равно нет, а память экономится.

Prefetch и serve-expired. Опции prefetch: yes и serve-expired: yes (обе рекомендуются для отзывчивости) держат «горячие» записи обновлёнными заранее и отдают устаревший ответ, пока идёт фоновое обновление — это добавляет немного накладных расходов памяти на структуры отслеживания, но выигрыш в задержке того стоит на слабом канале.

Установка на VPS

Из репозиториев большинства дистрибутивов Unbound ставится одной командой:

# Debian/Ubuntu
apt update && apt install unbound

# AlmaLinux/RHEL
dnf install unbound

Базовый рабочий конфиг для VPS с адекватным запасом памяти (/etc/unbound/unbound.conf.d/local.conf):

server:
    interface: 127.0.0.1
    interface: 10.0.0.2        # или внутренний IP, если резолвер общий для сети
    access-control: 10.0.0.0/24 allow
    access-control: 127.0.0.0/8 allow

    # DNSSEC
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # Память и производительность
    num-threads: 1
    msg-cache-size: 32m
    rrset-cache-size: 64m
    cache-min-ttl: 300
    prefetch: yes
    serve-expired: yes

    # Приватность
    hide-identity: yes
    hide-version: yes
    qname-minimisation: yes

После правки — перезапуск и проверка, что DNSSEC действительно валидирует:

systemctl restart unbound
dig sigfail.verteiltesysteme.net @127.0.0.1   # должен вернуть SERVFAIL
dig sigok.verteiltesysteme.net @127.0.0.1     # должен вернуть корректный ответ

Если первая команда не даёт SERVFAIL — валидация DNSSEC не работает, и стоит проверить, что auto-trust-anchor-file существует и unbound-anchor успешно скачал корневой ключ при первом запуске.

Связка с Pi-hole и AdGuard Home

Самый частый сценарий, ради которого вообще ставят Unbound на VPS — не голый резолвинг, а замена публичных upstream-серверов (8.8.8.8, 1.1.1.1) в блокировщике рекламы на собственный рекурсивный резолвер с DNSSEC. Смысл: блокировщик фильтрует домены, а Unbound избавляет от зависимости от чужого DNS-провайдера и от логирования ваших запросов третьей стороной.

Схема памяти в этом случае — сумма, а не пересечение: Pi-hole/FTL в покое ест 30-60 МБ (полный разбор), AdGuard Home — сопоставимо (разбор для AdGuard), Unbound добавляет свои 15-25 МБ плюс выделенный кэш. На VPS с 512 МБ-1 ГБ такая связка укладывается комфортно, если не раздувать кэш Unbound бездумно.

В Pi-hole подключение делается через веб-панель: Settings → DNS → Custom 1 (IPv4) — указываете 127.0.0.1#5335 (Unbound слушает не на 53, чтобы не конфликтовать с портом самого Pi-hole), предварительно поменяв порт в конфиге Unbound:

server:
    interface: 127.0.0.1@5335

В AdGuard Home то же самое настраивается в Settings → DNS settings → Upstream DNS servers: строка 127.0.0.1:5335.

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

В отличие от Pi-hole, где нехватка памяти чаще всего бьёт по обновлению gravity list раз в неделю, у Unbound проблема размазана по времени: при заниженном msg-cache-size/rrset-cache-size на активной сети кэш просто не успевает накапливать полезные записи — каждый запрос, даже к недавно резолвленному домену, идёт заново по всей рекурсивной цепочке. Симптом не «сервис упал», а «DNS стабильно медленный», хотя формально всё работает.

Если памяти физически не хватает и включён OOM killer, лог выглядит так:

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

После убийства процесса вся цепочка рушится: Pi-hole/AdGuard теряет upstream и либо не резолвит ничего, либо (если настроен fallback) молча уходит на публичный DNS — что сводит на нет весь смысл собственного резолвера. Проверка фактического потребления:

unbound-control stats | grep mem
free -h
systemctl status unbound

Команда unbound-control stats (требует включённого control-enable: yes в конфиге) показывает точные цифры по каждому виду кэша — mem.cache.rrset, mem.cache.message, mem.mod.iterator, mem.mod.validator — так что можно понять, какой именно лимит стоит подвинуть, а не гадать. Если сервер регулярно упирается в память, полезно сначала посмотреть на общий разбор признаков — что делать при нехватке RAM — а уже потом решать, добавлять своп или увеличивать тариф.

Тонкая настройка под ограниченную память

Если VPS ограничена по RAM (типичный минимальный тариф на 512 МБ-1 ГБ), но нужен именно рекурсивный резолвер с DNSSEC, а не форвардер — есть рычаги без потери функциональности.

Уменьшить кэш пропорционально нагрузке. Для 5-15 устройств домашней сети 16-32 МБ на msg-cache-size уже достаточно — прирост hit rate после этого порога небольшой относительно затраченной памяти.

Снизить TTL для serve-expired, чтобы не держать в памяти избыточно долго устаревшие записи:

serve-expired-ttl: 86400
serve-expired-client-timeout: 1800

Отключить лишние модули, если не нужны (например, so-reuseport не критичен на 1 vCPU):

so-reuseport: no

Ограничить slabs под низкую конкурентность — на 1-2 vCPU нет смысла в высоком msg-cache-slabs/rrset-cache-slabs (по умолчанию 4), это только дробит и без того небольшой кэш на мелкие сегменты:

msg-cache-slabs: 1
rrset-cache-slabs: 1

Мониторить реальное потребление после изменений, а не полагаться на теорию:

ps aux | grep unbound
cat /proc/$(pgrep unbound)/status | grep VmRSS

VmRSS (Resident Set Size) — это фактически занятая физическая память процесса, самый честный показатель для сверки с расчётами по конфигу.

Безопасность: закрытый резолвер, а не публичный

Отдельно стоит сказать про частую ошибку конфигурации, которая не про память, но напрямую влияет на стабильность сервера: Unbound без access-control по умолчанию слушает только localhost, и это правильно. Если вы открываете его на внешний интерфейс (например, чтобы резолвил для устройств вне локальной сети), обязательно ограничивайте access-control конкретной подсетью:

access-control: 10.0.0.0/24 allow
access-control: 0.0.0.0/0 refuse

Открытый на весь интернет рекурсивный резолвер на UDP-порту 53 — классический вектор DNS-амплификации: злоумышленник шлёт мелкие запросы с подделанным IP-адресом жертвы, ваш сервер отвечает объёмными DNSSEC-ответами именно ей, усиливая атаку в десятки раз. Правильная модель доступа — через VPN, аналогично тому, как это описано для Pi-hole в статье про WireGuard на Ubuntu 24.04: резолвер слушает только внутренний IP туннеля, клиенты подключаются и получают доступ к DNS-с-DNSSEC из любой точки, но не как открытый ресурс для всего интернета.

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