BIND9 named runaway memory usage: диагностика и ограничения кэша

Что значит «named memory usage runaway» и почему это часто не баг

Ситуация знакомая: сервер работает стабильно, но процесс named (BIND9) постепенно растёт по памяти, пока не упрётся в OOM или не начнёт активно свапить. В логах при этом может не быть ничего криминального — только обычные запросы. Такое «runaway memory usage» в контексте BIND9 чаще означает не утечку, а неконтролируемый рост данных, которые BIND хранит в оперативной памяти для ускорения резолвинга и применения политик.

BIND — высокопроизводительный DNS-движок, и память для него — инструмент ускорения. При включённой рекурсии и кэшировании процесс будет накапливать позитивные и негативные записи, метаданные для DNSSEC/EDNS, структуры обслуживания клиентов, а также данные для RPZ. Если лимиты не заданы или профиль трафика резко изменился, рост выглядит «убегающим».

Правильная диагностика начинается с ответа на вопрос «что именно растёт». Перезапуск — это сброс симптомов, а не лечение.

Обычно «раздуваться» могут: кэш, негативный кэш, RPZ-структуры, очереди или буферы логирования либо память растёт из‑за внешней нагрузки (например, открытая рекурсия наружу).

Быстрая первичная проверка на сервере

Перед правками конфигурации зафиксируйте контекст: версия BIND9, роль сервера (авторитативный/рекурсивный/смешанный), включены ли views, RPZ, DNSSEC-validation, query logging, какие ACL на рекурсию и кто может ходить на 53/udp и 53/tcp.

1) Убедиться, что проблема именно в памяти процесса named

Смотрите не только RSS, но и общую картину по системе: давление на память, swap, поведение journald, соседние сервисы. Большой VSZ при умеренном RSS обычно не страшен; стабильный рост RSS — повод копать.

ps -o pid,etimes,rss,vsz,cmd -C named
smem -p -P named
pmap -x $(pidof named) | tail -n 20

Если smem недоступен, ориентируйтесь на /proc:

grep -E 'VmRSS|VmSize|VmData|VmStk|VmExe|VmLib' /proc/$(pidof named)/status

2) Проверить, нет ли очевидного внешнего фактора

Чаще всего «виноват» не BIND как таковой, а трафик и режим работы.

• Резкий рост QPS (клиенты или приложение ушли в цикл резолвинга, сломался кеш у клиентов).

• Открытая рекурсия наружу (мусорный трафик, cache-busting, попытки абьюза).

• Включённый подробный query logging на бою.

• Тяжёлые RPZ-политики или RPZ-зоны, либо частые обновления RPZ.

ss -uanp | grep ':53 '
ss -tnp | grep named

Если видите много клиентов «снаружи», первым делом проверьте ограничения рекурсии и ACL. Это и безопасность, и контроль ресурса (кэш будет забиваться чужими запросами).

Если named крутится на сервере с множеством сервисов, иногда проще вынести резолвер на отдельную небольшую VDS и уже там настроить лимиты кэша и доступ по ACL — так вы изолируете риски OOM и получите предсказуемые «потолки» по RAM.

Сбор статистики BIND9: что смотреть в rndc stats и дампе кэша

Для практичного DNS troubleshooting важны встроенные счётчики: они не дадут идеальной «разбивки памяти по категориям», но покажут направление — растёт ли кэш, сколько отказов, какие типы запросов доминируют, есть ли лавина NXDOMAIN.

Проверить RNDC и снять статистику

Безопасный минимум — использовать rndc и локальные файлы статистики, не поднимая лишние слушающие сервисы.

rndc status
rndc stats

Чтобы посмотреть содержимое файла статистики, найдите statistics-file в выводе named-checkconf -p или просто поищите свежий файл рядом с data/cache каталогом BIND:

named-checkconf -p | sed -n '1,200p'
ls -lah /var/cache/bind
ls -lah /var/named/data

Дамп кэша полезен, но может быть тяжёлым по CPU и диску на нагруженном резолвере:

rndc dumpdb -cache

На что обращать внимание в stats/dumpdb

• Перекос по типам запросов: лавина ANY, TXT, HTTPS/SVCB или бесконечные запросы к случайным поддоменам.

• Большая доля негативных ответов (NXDOMAIN): они тоже кэшируются и могут раздувать структуры.

• Признаки cache-busting: каждый запрос уникален, кэш почти не помогает, но память занята метаданными и негативным кэшом.

Если хотите сравнить подходы и понять, когда BIND уместен как рекурсор, а когда проще иной стек — см. разбор PowerDNS и BIND: различия и сценарии применения.

Кэш BIND9 и память: max-cache-size, max-cache-ttl, max-ncache-ttl

Если BIND9 работает как рекурсивный резололвер, базовый «предохранитель» против runaway — лимитировать размер кэша и время жизни данных в нём. Это не гарантирует жёсткий потолок RSS, но на практике чаще всего даёт самый быстрый эффект.

Ограничение размера кэша (max-cache-size)

Параметр max-cache-size ограничивает объём кэша. Это не «жёсткая граница памяти процесса», но если основной потребитель — кэш, то рост RSS обычно стабилизируется.

options {
    max-cache-size 1024M;
};

Логику выбора держите простой: оставьте запас под сам named, RPZ/зоны, DNSSEC, системные буферы и соседние демоны. Если ограничить кэш слишком агрессивно, вы увеличите число обращений к апстримам и задержки.

Ограничение TTL позитивного кэша (max-cache-ttl)

max-cache-ttl полезен, если апстримы отдают чрезмерно длинные TTL, а вам не нужно держать записи часами или сутками. Это снижает «удержание» в памяти, но увеличивает повторные запросы.

options {
    max-cache-ttl 3600;
};

Ограничение негативного кэша (max-ncache-ttl)

При шуме в виде несуществующих поддоменов негативный кэш может заметно раздуваться. max-ncache-ttl ограничивает время кэширования NXDOMAIN/negative ответов.

options {
    max-ncache-ttl 300;
};

Если у вас много легитимных NXDOMAIN (например, приложения проверяют имена), слишком маленькое значение увеличит повторные запросы. Но при мусорном трафике это один из самых эффективных рычагов.

Stale cache: ускорение и скрытый потребитель памяти

Stale cache помогает переживать проблемы с апстримами: если авторитативные сервера временно недоступны, резолвер может вернуть «протухшую» запись, чтобы клиенты не падали. Для доступности это полезно, но для предсказуемости по памяти — ещё один слой кэширования и метаданных.

Синтаксис и поведение stale-опций зависит от ветки BIND9. Перед изменениями проверьте версию и «нормализованный» конфиг.

named -V
named-checkconf -p | sed -n '1,200p'

Если ваша цель — жёстче держать память, stale-режимы иногда стоит отключить или ужать. Делайте это осознанно: вы можете получить больше SERVFAIL при сбоях апстримов.

RPZ (response policy zone) и память: когда «dns firewall» становится тяжёлым

RPZ — мощный механизм политик: переписывание ответов, блокировки доменов/поддоменов и другие правила. Цена — память на зоны, индексы и обслуживание обновлений, особенно если правил много.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Типовые причины роста памяти из-за RPZ

• Слишком большая RPZ-зона (сотни тысяч или миллионы записей).

• Частые обновления RPZ, дающие пики и потенциальную фрагментацию.

• Несколько RPZ в разных views, которые фактически дублируют данные.

Как оценить влияние RPZ без «выключить и забыть»

Смотрите динамику памяти после reload/retransfer, контролируйте размеры зон и время обновлений. В тестовом окне можно временно исключить RPZ (или часть views) и сравнить «плато» RSS, но помните про риски для пользователей и безопасности.

rndc zonestatus rpz.example
rndc reload

Если вы используете policies и split-horizon, проверьте, не размножили ли вы RPZ по views без необходимости — часто это самый дорогой вариант. По теме views см. статью Split-horizon в BIND: views и типовые ошибки.

Query logging: как «удобство отладки» превращается в high memory usage

Query logging часто включают «на минутку», а потом забывают. Проблема даже не в диске: поток логов повышает CPU и I/O, увеличивает конкуренцию потоков и иногда раздувает внутренние очереди или буферы, что выглядит как повышенное потребление памяти.

Лучший подход: включать query logging точечно и на короткое время, по возможности ограничивая клиентов (ACL) и сохраняя логи в отдельный файл с понятной ротацией.

grep -R "querylog" -n /etc/bind 2>/dev/null
rndc status
journalctl -u named --since "1 hour ago" | tail -n 200

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

Этот чек-лист удобно проходить шаг за шагом, фиксируя метрики «до/после»: RSS процесса, QPS, долю NXDOMAIN/SERVFAIL, число клиентов, размер кэша.

1. Подтвердить роль сервера. Авторитативный, рекурсивный или смешанный. Для чисто авторитативного named большой кэш обычно не нужен.

2. Проверить рекурсию и ACL. Если рекурсия открыта наружу, вы получаете и риск, и рост кэша от чужого трафика.

3. Снять статистику. rndc status, rndc stats, при необходимости rndc dumpdb -cache в тихое окно.

4. Поставить предохранитель по кэшу. Ввести max-cache-size, затем при необходимости ограничить max-cache-ttl и max-ncache-ttl.

5. Проверить stale cache. Если включён — понять, нужен ли он вам именно в этом окружении.

6. Оценить RPZ. Размер зон, частоту обновлений, число правил и views.

7. Отключить query logging. Или оставить только точечный дебаг на короткое время.

8. Перезапуск — после фиксации причины. Иначе вы «сотрёте» симптомы и усложните расследование.

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

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Тонкости: почему память может не возвращаться системе сразу

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

Ориентируйтесь на тренды и «потолки», а не на ожидание, что после снижения QPS память сразу упадёт. Гораздо важнее, чтобы рост остановился после введения лимитов и нормализации трафика.

Минимальные безопасные примеры конфигурации для контроля кэша

Ниже — базовый набор опций для рекурсивного резолвера. Значения подбирайте под вашу RAM и профиль трафика.

options {
    recursion yes;

    max-cache-size 1024M;
    max-cache-ttl 3600;
    max-ncache-ttl 300;
};

После изменений проверьте синтаксис и примените конфигурацию без полного рестарта процесса:

named-checkconf
rndc reconfig

Когда всё же подозревать утечку или аномалию в версии BIND9

Настоящие memory leaks встречаются реже, чем «раздувание» кэша и функций вокруг него. Подозревать баг стоит, если рост воспроизводится на одном и том же трафике, не стабилизируется даже при жёстких лимитах кэша и выключенной рекурсии, либо если есть явная корреляция с конкретной фичей (RPZ, DNSSEC, нестандартные EDNS-паттерны).

Практичный путь на бою: обновиться в рамках поддерживаемой ветки вашего дистрибутива, сверить changelog на темы «memory leak», и только затем углубляться в профилирование. Сначала исключайте конфигурационные причины и мусорный трафик — это даёт максимальный эффект за минимальное время.

Итог: как победить high memory usage у named без «магических перезапусков»

Runaway memory usage у named почти всегда объясняется сочетанием факторов: неконтролируемый DNS cache, слишком большие TTL, лавина NXDOMAIN, включённый stale cache, тяжёлый RPZ и/или query logging. Правильный подход — собрать статистику (rndc stats), определить доминирующий источник роста и поставить предохранители: max-cache-size, затем при необходимости max-cache-ttl и max-ncache-ttl. После этого уже оптимизировать RPZ и процесс отладки, чтобы они не превращались в постоянную нагрузку.