Как установить и настроить PowerDNS на VPS

MAATRIX

Когда доменов становится больше пяти-шести, а у каждого свои NS-записи и субдомены, панель регистратора начинает мешать: медленный интерфейс, лимиты на количество записей, нет API для автоматизации. PowerDNS решает эту проблему — это авторитативный DNS-сервер, который хранит зоны не в текстовых файлах, как классический BIND, а в обычной базе данных (MySQL, PostgreSQL, SQLite). Значит, зонами можно управлять через SQL-запросы, скрипты и REST API, а не руками редактировать конфиги на каждом сервере отдельно. Ниже — рабочий путь: установка PowerDNS с бэкендом PostgreSQL, создание зон, настройка второго NS-сервера для отказоустойчивости и включение HTTP API.

Зачем свой DNS-сервер, а не панель регистратора

Панель регистратора удобна, пока доменов немного и записи меняются редко. Свой авторитативный DNS-сервер имеет смысл, когда вы управляете зонами программно (например, для мультитенантного SaaS, где под каждого клиента заводится поддомен), держите десятки доменов и хотите единый инструмент, или просто не готовы зависеть от доступности чужой панели в момент, когда нужно срочно поменять A-запись.

PowerDNS в этом плане выигрывает у BIND именно за счёт бэкенда БД: запись зоны — это строка в таблице, а не правка текстового файла с последующим rndc reload. Это открывает удобные сценарии — веб-интерфейс для клиентов, автоматическое создание поддоменов через API при регистрации нового пользователя, репликация зон между серверами через обычную репликацию базы данных.

Минус — дополнительная точка отказа: если база недоступна, PowerDNS с бэкендом БД (в отличие от файлового BIND) не сможет отвечать на запросы для новых зон, пока не восстановит соединение. На практике это редко становится проблемой: PostgreSQL и MySQL стабильны, а PowerDNS кэширует ответы, так что кратковременная просадка базы не обрушивает резолвинг мгновенно.

Что нужно перед установкой

Для авторитативного DNS-сервера хватает скромного VPS: 1 ядро, 1-2 ГБ RAM, 10-20 ГБ диска — сама служба лёгкая, нагрузку создаёт в основном PostgreSQL, если он на том же сервере. Для боевой конфигурации нужно минимум два сервера в разных сетях (а лучше — в разных дата-центрах) под primary и secondary NS: это требование большинства регистраторов и просто разумная отказоустойчивость.

Определитесь с локацией: если основная аудитория пользователей в России, логично взять RU-сервер под primary NS для минимального пинга. Secondary можно разместить в другой локации — например, US или UK — чтобы поймать частичный сбой сети или блокировку в одном регионе, а не потерять резолвинг целиком.

В примерах — Ubuntu 24.04 LTS, доступ по SSH-ключу, пользователь с правами sudo. Домен уже делегирован (NS-записи у регистратора указывают на ваши будущие серверы) — этот шаг нужно сделать отдельно у регистратора, здесь я его не описываю.

Установка PowerDNS и PostgreSQL-бэкенда

В репозиториях Ubuntu 24.04 версия PowerDNS не самая свежая, но для большинства задач вполне рабочая. Ставим сам сервер, бэкенд для PostgreSQL и клиент базы:

sudo apt update
sudo apt install -y pdns-server pdns-backend-pgsql postgresql postgresql-contrib

Создайте базу и роль для PowerDNS:

sudo -u postgres psql -c "CREATE ROLE pdns WITH LOGIN PASSWORD 'слоЖный_Пароль_2026';"
sudo -u postgres psql -c "CREATE DATABASE pdns OWNER pdns;"

PowerDNS ожидает конкретную схему таблиц. Актуальную SQL-схему для PostgreSQL проще всего взять из установленного пакета — она лежит в /usr/share/pdns-backend-pgsql/schema/schema.pgsql.sql — или свериться с официальной документацией PowerDNS перед применением, поскольку структура иногда меняется между версиями:

sudo -u postgres psql pdns < /usr/share/pdns-backend-pgsql/schema/schema.pgsql.sql

Если файла нет по этому пути, найдите его командой dpkg -L pdns-backend-pgsql | grep sql — расположение может отличаться в зависимости от версии пакета.

Настройка бэкенда и запуск службы

Основной конфиг PowerDNS — /etc/powerdns/pdns.conf. Подключаем PostgreSQL-бэкенд:

sudo nano /etc/powerdns/pdns.conf

launch=gpgsql
gpgsql-host=127.0.0.1
gpgsql-port=5432
gpgsql-dbname=pdns
gpgsql-user=pdns
gpgsql-password=слоЖный_Пароль_2026

По умолчанию PowerDNS слушает 53 порт на всех интерфейсах — это ожидаемо для авторитативного сервера, который должен отвечать на внешние DNS-запросы. Но убедитесь, что рекурсия выключена (иначе сервер превращается в открытый резолвер, которым можно злоупотребить для DDoS-атак с усилением):

allow-recursion=127.0.0.1
recursor=no

Перезапустите службу и проверьте статус:

sudo systemctl restart pdns
sudo systemctl status pdns

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

sudo journalctl -u pdns -n 50

Создание зоны и записей через pdnsutil

Утилита pdnsutil — самый простой способ создать зону и записи без прямых SQL-запросов к базе. Создаём зону для домена (замените на свой):

sudo pdnsutil create-zone example.ru ns1.example.ru

Добавляем базовые записи:

sudo pdnsutil add-record example.ru @ A 3600 203.0.113.10
sudo pdnsutil add-record example.ru www A 3600 203.0.113.10
sudo pdnsutil add-record example.ru @ MX 3600 "10 mail.example.ru."
sudo pdnsutil add-record example.ru ns2 A 3600 198.51.100.20

Проверьте, что зона отдаётся корректно, запросом к самому серверу:

dig @127.0.0.1 example.ru A
dig @127.0.0.1 example.ru NS

Если ответ содержит нужные записи и флаг AA (Authoritative Answer) в заголовке — сервер настроен верно и отвечает как авторитативный источник для этой зоны. После проверки на localhost стоит убедиться, что запись доступна и снаружи, с другого хоста: dig @ваш_внешний_ip example.ru A.

Secondary-сервер и репликация зон

Один DNS-сервер — точка отказа: если он недоступен, домен перестаёт резолвиться. Регистраторы обычно и технически требуют минимум два NS-сервера. PowerDNS поддерживает нативную репликацию зон через AXFR — secondary-сервер сам подтягивает зоны у primary.

На secondary-сервере (тоже с установленным PowerDNS и бэкендом БД) укажите primary как источник зоны:

sudo pdnsutil create-secondary-zone example.ru 203.0.113.10

На primary разрешите передачу зоны конкретному IP secondary-сервера — без ограничения AXFR открыт кому угодно, а это утечка полного списка ваших поддоменов и потенциальная разведка перед атакой:

sudo nano /etc/powerdns/pdns.conf

allow-axfr-ips=198.51.100.20
also-notify=198.51.100.20

После правки перезапустите PowerDNS на обоих серверах. Проверить, что передача зоны реально произошла, можно на secondary через pdnsutil list-zone example.ru — если записи совпадают с primary, репликация работает. Не забудьте прописать у регистратора NS-записи на оба сервера — только тогда резолверы в интернете будут опрашивать их оба и переключаться на secondary при недоступности primary.

HTTP API и веб-интерфейс

Одно из главных преимуществ PowerDNS перед BIND — встроенный REST API, через который можно создавать зоны и записи программно, не заходя на сервер по SSH. Включается в том же конфиге:

api=yes
api-key=длинный_случайный_ключ_2026
webserver=yes
webserver-address=127.0.0.1
webserver-port=8081

Оставляйте webserver-address=127.0.0.1, чтобы API не торчал в интернет напрямую — доступ снаружи организуйте через nginx как обратный прокси с TLS и дополнительной авторизацией, либо через SSH-туннель для разового администрирования. Настройку самого nginx как reverse proxy можно посмотреть в статье про настройку nginx как reverse proxy, логика для API-порта аналогична.

После перезапуска службы проверьте API запросом:

curl -H "X-API-Key: длинный_случайный_ключ_2026" http://127.0.0.1:8081/api/v1/servers/localhost/zones

В ответ должен прийти JSON со списком ваших зон. Через тот же API можно добавлять записи PATCH-запросом к /api/v1/servers/localhost/zones/example.ru — это удобно, если вы пишете панель для клиентов или автоматизируете создание поддоменов при регистрации.

Для визуального управления есть сторонние веб-интерфейсы, например PowerDNS-Admin — он обращается к тому же API и базе, но даёт удобную панель с ролями пользователей вместо ручных curl-запросов.

Безопасность и обслуживание

Закройте лишние порты фаерволом: снаружи нужен только 53/udp и 53/tcp (DNS-запросы), веб-интерфейс API держите на localhost или за отдельной авторизацией. Разбор общих принципов настройки фаервола — в статье про настройку UFW на VPS.

sudo ufw allow 53/tcp
sudo ufw allow 53/udp

Регулярно бэкапьте базу PostgreSQL с зонами — потеря базы означает потерю всех записей для всех доменов разом, а не одного файла зоны, как было бы с BIND. Принципы дампа и восстановления такие же, как для любой PostgreSQL-базы — подробно они разобраны в статье про установку и настройку PostgreSQL на VPS.

sudo -u postgres pg_dump -Fc pdns > /var/backups/pdns_$(date +%F).dump

Следите за журналом службы на предмет ошибок AXFR-репликации между primary и secondary — рассинхронизация зон обычно проявляется не сразу, а через несколько дней, когда TTL старых записей истечёт и клиенты начнут получать разные ответы с разных серверов. Также стоит понимать, что PowerDNS в описанной здесь конфигурации — это только авторитативный сервер, он не отвечает на произвольные рекурсивные запросы клиентов из интернета; если нужен ещё и рекурсивный резолвер (например, для внутренней сети), для этого у PowerDNS есть отдельный продукт — PowerDNS Recursor, который разворачивается отдельно.

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