BIND9 или PowerDNS: что выгоднее и когда

MAATRIX

Если у вас три домена и они годами не меняются — любой DNS-сервер справится, и спор бессмыслен. Но как только доменов становится десятки или сотни, а зоны нужно менять автоматически из панели или скрипта, выбор между BIND9 и PowerDNS перестаёт быть формальностью. Один — эталон надёжности на текстовых файлах, второй — DNS с базой данных и API под автоматизацию. Разберём, чем они отличаются на практике и когда какой выгоднее.

Коротко: два разных подхода к авторитативному DNS

BIND9 (Berkeley Internet Name Domain) — это эталонная реализация DNS-протокола, на которой десятилетиями держится половина интернета. Зоны хранятся в текстовых файлах формата RFC 1035, конфигурация — в named.conf, а любое изменение зоны обычно означает правку файла и rndc reload. Это низкоуровневый, предсказуемый инструмент без лишних абстракций: то, что написано в файле, то и отдаётся резолверам.

PowerDNS устроен иначе с самого начала: зоны хранятся не в файлах, а в бэкенде — MySQL, PostgreSQL, SQLite или даже в стороннем API. Поверх есть встроенный REST API, через который можно программно создавать домены, добавлять записи и получать статистику без единого reload. PowerDNS изначально проектировался под сценарий «много доменов, которые меняются автоматически», а не «несколько зон, которые правит администратор руками».

Разница не в том, какой сервер «лучше умеет DNS» — оба полностью соответствуют протоколу и поддерживают DNSSEC. Разница в модели хранения данных и в том, насколько удобно встроить сервер в автоматизацию.

BIND9: текстовые зоны и репутация стандарта

Установка занимает минуту:

apt install -y bind9 bind9utils dnsutils
systemctl enable --now bind9
named-checkconf

Зона описывается файлом:

$TTL 3600
@   IN SOA ns1.example.com. admin.example.com. (
        2026090101 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        3600 )     ; minimum
    IN NS ns1.example.com.
    IN NS ns2.example.com.
@   IN A  203.0.113.10
www IN A  203.0.113.10

и подключается в named.conf.local:

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
};

После любой правки — named-checkconf, затем rndc reload или systemctl reload bind9. Никакой базы данных, никакого API — вся логика прозрачна и лежит в файловой системе, что удобно для бэкапов через обычный git или rsync и для аудита изменений построчно в diff. Именно эта простота и десятилетия эксплуатации в критичной инфраструктуре сделали BIND9 стандартом де-факто — с ним совместим практически любой учебник, гайд и legacy-скрипт автоматизации.

Обратная сторона: при сотнях доменов ручное редактирование файлов и увеличение serial при каждой правке становится рутиной, которую придётся автоматизировать самостоятельно — штатных инструментов для программного управления зонами в BIND9 нет. Подробный процесс установки на чистой машине разобран в статье про установку BIND9 на VPS.

PowerDNS: база данных, бэкенды и REST API

Установка с бэкендом SQLite для теста или MySQL/PostgreSQL для продакшена:

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

Фрагмент pdns.conf:

launch=gmysql
gmysql-host=127.0.0.1
gmysql-dbname=pdns
gmysql-user=pdns
gmysql-password=secret
api=yes
api-key=change-me
webserver=yes

Дальше домены и записи управляются либо утилитой pdnsutil:

pdnsutil create-zone example.com ns1.example.com
pdnsutil add-record example.com www A 203.0.113.10

либо напрямую через REST API:

curl -X POST -H "X-API-Key: change-me" \
  http://127.0.0.1:8081/api/v1/servers/localhost/zones/example.com/rrsets \
  -d '{"rrsets":[{"name":"www.example.com.","type":"A","ttl":3600,"changetype":"REPLACE","records":[{"content":"203.0.113.10","disabled":false}]}]}'

Изменение попадает в базу и отдаётся резолверам без перезагрузки сервиса — это ключевое отличие от BIND9. На этом API строятся веб-панели вроде PowerDNS-Admin, а также интеграции с провижининг-системами хостинга: создал аккаунт клиента — скрипт тем же вызовом создал зону и записи. Это и есть главная причина, по которой PowerDNS выбирают хостинги и SaaS-проекты. Пошаговая установка на VPS с нуля — в статье про установку PowerDNS.

Плата за гибкость — дополнительный компонент инфраструктуры: СУБД, которую нужно бэкапить, реплицировать и защищать отдельно от самого DNS-сервера. Для одного человека с десятком статичных доменов это избыточная сложность без реальной выгоды.

Сравнение по ключевым критериям

Ресурсы и обслуживание в эксплуатации

Оба сервера легковесны по меркам современного VPS и запускаются на минимальной конфигурации — конкретные требования по памяти для каждого разобраны отдельно, в статьях сколько RAM нужно для BIND9 и сколько RAM нужно для PowerDNS; в общих чертах, память в основном зависит от количества зон и записей, а не от выбора самого движка. Реальная разница — в характере обслуживания, а не в потреблении ресурсов.

BIND9 не требует ничего, кроме самого процесса named: нет БД, нечего реплицировать, бэкап — это копия каталога с зонами. PowerDNS добавляет обслуживание СУБД: резервное копирование базы, мониторинг её доступности, а при росте нагрузки — возможную репликацию MySQL/PostgreSQL между master и slave DNS-серверами. Это не «дороже» по железу, но требует больше операционного внимания: одна лишняя точка отказа, которую нужно администрировать. Если вы уже держите MySQL или PostgreSQL под другими проектами на этом сервере, добавление PowerDNS почти ничего не стоит; если базы данных в инфраструктуре нет вообще, разворачивать её ради DNS — заметный шаг в сложности.

Что выбрать под сценарий

Берите BIND9, если у вас конечное число доменов (от одного до нескольких десятков), зоны меняются нечасто и вручную, а важнее всего предсказуемость, совместимость с любой документацией в интернете и минимум движущихся частей. Это выбор по умолчанию для личных проектов, небольших компаний, авторитативных серверов внутри корпоративной сети и всех, кто ценит «поставил и годами не трогаешь».

Берите PowerDNS, если доменов много, они создаются и удаляются программно (хостинг, SaaS с поддоменами на клиента, DNS как часть внутренней платформы), и вам нужен API для интеграции с биллингом или панелью управления. Здесь PowerDNS экономит реальное время разработки: вместо генерации зонных файлов скриптом и rndc reload — один HTTP-запрос. Дополнительный плюс: PowerDNS хорошо сочетается с dnsdist перед собой для балансировки нагрузки между несколькими бэкендами, что уместно при высоком трафике запросов.

Важный нюанс: серверы не обязательно взаимоисключающие. Частая рабочая схема — PowerDNS как master с базой и API для управления, а BIND9 или второй PowerDNS в роли slave, забирающего зоны по AXFR/IXFR для географического резервирования. Оба сервера полностью совместимы по протоколу передачи зон, так что смешивать их в одной инфраструктуре — нормальная практика, а не компромисс.

Для обоих вариантов нужен сервер с постоянным аптаймом, статичным IP и, для критичных зон, желательно несколько geo-распределённых точек — эту тему разбирает статья про Geo-DNS. В MAATRIX можно арендовать VPS в нужной локации под авторитативный DNS-сервер и оплатить картой российского банка, по СБП, криптовалютой или токеном MAAT — без иностранной карты и посредников.

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