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

MAATRIX

Если вы поднимаете собственный авторитативный DNS для своих доменов через PowerDNS, вопрос про RAM обычно звучит расплывчато — «сколько нужно, чтобы не упало». Ответ зависит не от самого PowerDNS (он лёгкий), а от того, какой бэкенд вы выбрали и что реально грузит память — сам процесс pdns_server или база данных за ним. Разберём по частям, чтобы не переплачивать за VPS и не упереться в OOM на проде.

Как PowerDNS расходует память: authoritative vs recursor

PowerDNS — это на самом деле два разных продукта с разными профилями памяти, и их часто путают:

• PowerDNS Authoritative Server (pdns-server) — отвечает на запросы о ваших собственных зонах. Он не хранит все записи в памяти целиком, как это делает BIND с zone-файлами, а на каждый запрос (с учётом кэша) обращается к бэкенду — файлу, SQLite или внешней БД. Сам процесс лёгкий: пустой сервер с парой зон занимает порядка 30-60 МБ резидентной памяти, рост зависит в основном от числа потоков (receiver-threads, distributor-threads) и размера packet-cache/query-cache.
• PowerDNS Recursor (pdns-recursor) — отдельный демон-резолвер, который ходит в интернет и кэширует чужие ответы. У него своя память, завязанная на max-cache-entries (по умолчанию около миллиона записей) — это отдельная статья расходов, никак не связанная с числом ваших доменных зон.

Если задача — «своя авторитативная DNS-зона для своих доменов», вам почти наверняка нужен только authoritative-сервер. Recursor поднимают отдельно и по другому поводу (например, для внутреннего кэширующего резолвера), и объединять их на одном публичном IP — плохая идея, об этом ниже в разделе про безопасность.

Bind-бэкенд vs SQL-бэкенды: где на самом деле живёт память

PowerDNS поддерживает несколько бэкендов, и они принципиально разные по требованиям к RAM:

• bind-backend — классические zone-файлы, как у BIND. Никакой СУБД не нужно, память минимальна (сам процесс + кэш), подходит, если зоны редактируются руками или скриптом и не нужен веб-интерфейс с динамическими правками.
• gmysql / gpgsql — зоны и записи хранятся в MySQL/MariaDB или PostgreSQL. Это то, что имеется в виду в задаче: DNS-сервер с БД-бэкендом. Такой подход даёт удобное управление через SQL, API (pdns_server умеет отдавать встроенный REST API) или веб-панель, но добавляет к затратам памяти саму СУБД — а она может весить куда больше, чем сам PowerDNS.
• sqlite3 — компромисс: SQL-интерфейс без отдельного сервера БД, минимальный оверхед по памяти, но не годится для сценариев с частой параллельной записью или репликацией.

Важный момент: когда вы спрашиваете «сколько RAM для PowerDNS с MySQL», по факту вы спрашиваете «сколько RAM для PowerDNS + сколько для MySQL под DNS-нагрузку». Это разные цифры, и вторая обычно больше первой.

Сколько RAM закладывать: ориентировочные сценарии

Точных универсальных цифр тут не существует — многое зависит от QPS, настроек кэша и того, крутится ли на той же машине что-то ещё. Но по порядку величины ориентироваться можно так:

Эти цифры — ориентир для планирования, а не гарантированный бенчмарк: у вас на конкретной нагрузке (частые AXFR, много одновременных клиентов резолверов, включённый DNSSEC-подписи на лету) потребление может отличаться в обе стороны. DNSSEC добавляет CPU на подпись зон при обновлении, но на RAM влияет некритично для типичных объёмов.

Практический вывод: если у вас до сотни зон и это не высоконагруженный публичный DNS-хостинг, спокойно хватает VPS на 1-2 ГБ RAM с MySQL/PostgreSQL на борту. Ниже 1 ГБ имеет смысл только с bind- или sqlite-бэкендом, где СУБД вообще нет.

Установка и настройка на VPS

Пример для Debian/Ubuntu с MariaDB — типичная связка для собственных зон:

apt update
apt install pdns-server pdns-backend-mysql mariadb-server -y

Создаём базу и пользователя:

CREATE DATABASE pdns;
CREATE USER 'pdns'@'localhost' IDENTIFIED BY 'СЛОЖНЫЙ_ПАРОЛЬ';
GRANT ALL PRIVILEGES ON pdns.* TO 'pdns'@'localhost';
FLUSH PRIVILEGES;

Импортируем схему — пакет обычно кладёт файл со схемой в документацию, точный путь проверяйте на своей системе:

dpkg -L pdns-backend-mysql | grep schema
# например: /usr/share/doc/pdns-backend-mysql/schema.mysql.sql.gz
zcat /usr/share/doc/pdns-backend-mysql/schema.mysql.sql.gz | mysql -u root -p pdns

Настраиваем бэкенд в /etc/powerdns/pdns.conf:

launch=gmysql
gmysql-host=127.0.0.1
gmysql-port=3306
gmysql-dbname=pdns
gmysql-user=pdns
gmysql-password=СЛОЖНЫЙ_ПАРОЛЬ

local-address=0.0.0.0
local-port=53

# не светить версию наружу
version-string=anonymous

Перезапускаем и проверяем:

systemctl restart pdns
systemctl status pdns
dig @127.0.0.1 ваш-домен.ru SOA

Зоны и записи после этого добавляются либо напрямую в таблицы domains/records, либо через pdnsutil, либо через встроенный REST API (api=yes, api-key=..., webserver=yes) — что удобнее для вашего рабочего процесса. Если у вас уже настроен MySQL или PostgreSQL для других задач на сервере, шаги установки и тюнинга самой СУБД подробно разобраны в статьях про установку и настройку MySQL на VPS и установку и настройку PostgreSQL на VPS — принципы буферизации и памяти там те же самые.

Безопасность: чтобы DNS-сервер не стал орудием DDoS

Раз категория — security, отдельно стоит проговорить главную ошибку при поднятии своего DNS: не превращайте authoritative-сервер в открытый рекурсивный резолвер. Если PowerDNS отвечает на запросы о чужих доменах для любого IP в интернете, его используют для DNS-amplification атак на третьих лиц — небольшой запрос порождает большой ответ, и весь этот трафик летит жертве, а не вам, но с вашего IP.

Что стоит сделать сразу:

• Держите pdns-recursor (если он вообще нужен) только на внутреннем интерфейсе или за файрволом, ограничив allow-from вашими сетями — никогда не публичным 0.0.0.0 без ограничений.
• На authoritative-сервере ограничьте зонные трансферы (AXFR) конкретными IP через allow-axfr-ips, а лучше используйте TSIG-ключи для вторичных серверов.
• Закройте веб-интерфейс/API PowerDNS (webserver, api) файрволом или биндом только на localhost/VPN — это управляющий интерфейс, ему нечего делать в публичном доступе.
• Настройте на уровне iptables/nftables базовый rate-limit на UDP/53, чтобы аномальный всплеск запросов не положил сервер и не использовался для отражённой атаки через ваш IP.

Отдельно от «сколько памяти» — это как раз тот случай, когда неправильная конфигурация обходится не медленной работой, а жалобами хостера и абузами на ваш IP.

Мониторинг потребления памяти и типичные проблемы

Проверить, что реально ест память, несложно:

ps aux --sort=-%mem | grep -E 'pdns|mysqld|postgres' | head
free -h
pdns_control status
journalctl -u pdns -n 50

Если стоит MySQL — посмотреть на буфер и статистику InnoDB:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW ENGINE INNODB STATUS\G

Для PostgreSQL — аналогично shared_buffers и pg_stat_activity. Для DNS-нагрузки (короткие простые запросы, небольшой объём данных) стандартных настроек буфера обычно достаточно, задирать их «на всякий случай» смысла немного — лишняя память, зарезервированная под буфер, который никогда не заполнится, просто простаивает.

Если видите, что сервер уходит в swap или систему убивает OOM killer — чаще всего дело не в PowerDNS, а в том, что на той же VPS крутится что-то ещё (веб-сервер, другие сервисы), и общая память сервера уже не соответствует нагрузке. Общий подход к диагностике нехватки RAM на сервере — в статье что делать при нехватке RAM. Для самой связки DNS+БД имеет смысл через systemd поставить разумный MemoryMax на MySQL/PostgreSQL, чтобы при аномалии убивало именно её процесс контролируемо, а не ронял весь сервер вместе с PowerDNS.

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