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

MAATRIX

BIND9 — самый старый и самый распространённый DNS-сервер в индустрии, и вопрос «сколько ему нужно памяти» звучит просто, но ответ сильно зависит от роли сервера. Авторитетный BIND9, который отдаёт ваши собственные зоны, и рекурсивный резолвер, который ходит в интернет за чужими ответами и кэширует их, — это два разных профиля потребления памяти, различающиеся на порядок. Разберёмся, откуда берётся расход в каждом случае и как не попасть ни в недобор, ни в переплату за VPS.

Два режима работы — два разных бюджета памяти

Первое, что нужно понять: BIND9 не «весит X мегабайт» — он весит по-разному в зависимости от того, что вы от него хотите.

Авторитетный сервер (authoritative-only) хранит в памяти содержимое зон, которые обслуживает: A/AAAA/MX/TXT/NS-записи, SOA, при DNSSEC — ещё и подписи. Память тут пропорциональна размеру и количеству зон, а не количеству запросов. Сервер на 20 небольших доменов и сервер на 20 000 доменов — это принципиально разные машины, даже если оба отвечают на одинаковое число запросов в секунду.

Рекурсивный резолвер (recursion yes) сам по себе для чужих зон почти ничего не хранит долговременно — он строит кэш ответов, которые сам же получил от других серверов, и кэш этот живёт по TTL записей. Память тут зависит не от «сколько доменов вы обслуживаете», а от того, сколько уникальных запросов проходит через резолвер и как долго вы разрешаете кэшу расти (max-cache-size).

Отдельно стоит связка «и то и другое сразу» (authoritative + recursion на одном процессе) — так делать не рекомендуется по соображениям безопасности (кэш-отравление, амплификация), но с точки зрения памяти это просто сумма двух бюджетов.

Авторитетный сервер: сколько весит зона

Зона в памяти BIND9 хранится в структуре RBTDB (red-black tree database) — это не построчное чтение файла, а дерево с указателями, метаданными TTL, счётчиками ссылок и служебными полями на каждую запись. Из-за этого зона в памяти всегда весит заметно больше, чем текстовый zone-файл на диске — по опыту администраторов BIND, множитель обычно находится в диапазоне от 2 до 5 раз, точное число зависит от версии BIND, количества типов записей и того, включён ли DNSSEC. Это ориентир, не гарантия — на своих зонах стоит измерить фактически (см. раздел про диагностику ниже).

Практические ориентиры для авторитетного сервера без DNSSEC:

Для подавляющего большинства задач — «домен компании плюс десяток поддоменов» — авторитетный BIND9 комфортно живёт на 512 МБ-1 ГБ RAM вместе с ОС, и это без всякого запаса на кэш, потому что recursion в такой конфигурации выключен.

Рекурсивный резолвер: кэш решает всё

Если вы поднимаете BIND9 как резолвер для офиса, VPN-сети или как публичный DNS, главный потребитель памяти — не сама программа (её базовый footprint — десятки мегабайт), а кэш ответов.

Ключевая настройка — max-cache-size в блоке options:

options {
    recursion yes;
    listen-on { 10.0.0.1; };
    allow-recursion { 10.0.0.0/24; };

    max-cache-size 512m;
    max-cache-ttl 3600;
    max-ncache-ttl 900;
};

Без явного ограничения поведение зависит от версии: в старых сборках BIND9 кэш по умолчанию не ограничен вообще (пока не сработает serve-stale или своп не начнёт душить систему), в более новых версиях действует ограничение по проценту доступной памяти хоста. Полагаться на дефолт не стоит в любом случае — на VPS с фиксированным лимитом RAM лучше всегда прописывать max-cache-size явно, иначе при DDoS-подобном шторме уникальных запросов (NXDOMAIN-флуд, случайные поддомены) кэш будет расти, пока не упрётся в OOM killer.

Ориентировочная зависимость размера кэша от нагрузки (именно ориентир — реальные цифры зависят от TTL записей в зоне, разнообразия запрашиваемых доменов и того, сколько NXDOMAIN-ответов кэшируется):

• Домашняя сеть, 5-20 устройств: кэш редко превышает 20-50 МБ, хватает max-cache-size 128m.
• Малый офис, 50-200 клиентов, разнообразный трафик: реалистично закладывать max-cache-size 256m-512m.
• Резолвер для VPN-провайдера или крупной инфраструктуры с тысячами уникальных клиентов: max-cache-size 1g-2g и выше, плюс отдельное внимание к recursive-clients (лимит одновременных рекурсивных запросов, по умолчанию 1000 — при высокой параллельности каждый «висящий» запрос тоже держит память).

DNSSEC: недооценённый множитель памяти

Если зона подписана DNSSEC, в памяти дополнительно хранятся RRSIG-записи (по одной-две на каждый набор записей), NSEC/NSEC3-записи для доказательства отсутствия домена и сами ключи. На практике это добавляет от 30% до кратного увеличения объёма зоны в памяти — разброс большой, потому что зависит от алгоритма подписи (RSA-подписи заметно тяжелее ECDSA) и от того, используется ли NSEC3 с большим числом итераций.

Для рекурсивного резолвера DNSSEC работает иначе: он должен кэшировать не только ответ, но и цепочку подписей для валидации (DNSKEY, RRSIG, чейн доверия до корня), что при dnssec-validation yes (это разумный дефолт в современных версиях) увеличивает средний размер закэшированной записи. На резолвере с активной DNSSEC-валидацией стоит закладывать на 20-40% больше памяти под кэш по сравнению с той же нагрузкой без валидации — опять же ориентировочно, точную цифру даёт только измерение на вашем трафике.

Как измерить фактическое потребление, а не гадать

Гадать не обязательно — BIND9 умеет честно показывать, сколько памяти он использует.

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

rndc stats
# статистика пишется в named.stats (обычно /var/cache/bind/named.stats)
grep -A 20 "Memory usage" /var/cache/bind/named.stats

Там будет разбивка по memory-контекстам: сколько выделено под кэш, сколько под каждую зону, сколько под служебные структуры.

Второй способ — канал статистики по HTTP, если он включён:

statistics-channels {
    inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
};

curl -s http://127.0.0.1:8053/xml/v3/mem | less

Это даёт живую картину в момент запроса — удобно снимать под нагрузкой, а не только на старте, потому что кэш прогревается не сразу.

Третий способ — просто системный ps/top по процессу named, грубо, но быстро:

ps -o pid,rss,vsz,comm -C named

RSS (resident set size) в килобайтах — это реальное потребление физической памяти на данный момент, полезно смотреть в динамике (watch -n 5 'ps -o rss,comm -C named') в течение суток, чтобы поймать пик, а не мгновенный снимок.

Конфигурация под конкретный объём VPS

Ниже — рабочие профили named.conf.options под типичные размеры серверов. Это отправная точка, не догма — подстройте под свои зоны и трафик.

512 МБ RAM, авторитетный сервер, до ~50 небольших зон, recursion выключен:

options {
    recursion no;
    allow-query { any; };
    max-cache-size 0;
};

Recursion выключен намеренно — на маленькой машине незачем держать открытый резолвер, это и вопрос безопасности (защита от DNS-амплификации), и экономия памяти.

1-2 ГБ RAM, резолвер для локальной сети или небольшого VPN-провайдера:

options {
    recursion yes;
    allow-recursion { 10.0.0.0/8; 192.168.0.0/16; };
    max-cache-size 512m;
    recursive-clients 2000;
    dnssec-validation auto;
};

4+ ГБ RAM, авторитетный DNS-хостинг на сотни-тысячи зон с DNSSEC:

options {
    recursion no;
    max-cache-size 0;
    max-journal-size 16m;
    transfers-in 20;
    transfers-out 20;
};

dnssec-policy default;

Здесь основной расход — сами зоны и подписи, поэтому важнее следить за rndc stats по мере роста количества доменов, чем упираться в готовую цифру.

Типичные грабли, которые едят память незаметно

• Открытый рекурсивный резолвер без allow-recursion. Если резолвер отвечает на рекурсивные запросы от кого угодно из интернета, его начинают использовать в DDoS-амплификации — тысячи уникальных запросов от ботнета раздувают кэш и грузят CPU одновременно. Всегда ограничивайте allow-recursion своей сетью.
• Забытый max-cache-size. На VPS с 1 ГБ RAM резолвер без лимита кэша рано или поздно съедает всё свободное и уходит в своп или под нож OOM killer — обычно в самый неподходящий момент, под пиковой нагрузкой.
• Зомби-зоны в конфиге. Тестовые или давно неиспользуемые зоны, которые никто не убрал из named.conf, продолжают жить в памяти и грузиться при рестарте — периодическая ревизия конфига экономит и память, и время на диагностику.
• serve-stale без ограничения. Функция «отдавать устаревший кэш, если апстрим недоступен» полезна для отказоустойчивости, но max-stale-ttl стоит явно ограничить — иначе устаревшие записи копятся в памяти дольше, чем нужно.
• Слишком большой recursive-clients на маленькой машине. Каждый одновременный рекурсивный запрос держит структуры в памяти, пока не получит ответ — при лимите в тысячи на VPS с 512 МБ вы скорее упрётесь в память, чем реально используете такую параллельность.

Если планируете DNS-инфраструктуру с нуля, полезно заодно свериться со смежными материалами: базовую настройку зон разбираем в статье про домен и DNS с нуля на Ubuntu 24.04, альтернативный современный сервер — в статье про установку PowerDNS на VPS, а общий подход к резерву памяти под сервер целиком — в материале сколько оперативной памяти закладывать с запасом.

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