Когда есть смысл держать собственный BIND 9 вместо DNS-провайдера

Управляемый DNS у регистратора или хостинга закрывает большинство задач, но не все. Свой BIND 9 нужен, если у вас собственный ASN и вы строите Anycast-сеть, если требуется нестандартная логика зоны через скрипты и представления (views), либо если политика безопасности запрещает хранить зону у стороннего провайдера. Плата за это — вы сами отвечаете за обновления, отказоустойчивость и защиту сервера от DDoS.

Установка BIND 9 и ключевые файлы конфигурации

На Debian или Ubuntu сервер поднимается так:

sudo apt update
sudo apt install bind9 bind9utils bind9-doc -y

Конфигурация разбита на несколько файлов с чёткой ролью каждого:

Файл	Назначение
/etc/bind/named.conf.options	Глобальные параметры: рекурсия, forwarders, слушаемые адреса
/etc/bind/named.conf.local	Список зон, за которые отвечает сервер
/etc/bind/zones/db.example.com	Содержимое конкретной зоны: записи A, NS, MX и другие
/var/log/syslog	Журнал запуска и ошибок named

Описание зоны в named.conf.local

Каждая зона объявляется отдельным блоком:

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { 203.0.113.53; };
    also-notify { 203.0.113.53; };
};

Директива allow-transfer разрешает передачу зоны только перечисленным IP вторичных серверов, а also-notify заставляет мастер сразу уведомлять их об изменении серийного номера, не дожидаясь истечения refresh-интервала.

Файл зоны: SOA, NS, A и другие записи

Сам файл зоны описывает содержимое домена:

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

Серийный номер (serial) обязательно увеличивается при каждой правке, иначе вторичные серверы не подтянут новую версию зоны. Про работу этих типов записей в целом рассказано в отдельной статье базы знаний.

Проверка синтаксиса и перезагрузка зоны

Перед перезапуском named синтаксис стоит проверить утилитами из пакета bind9utils:

named-checkconf
named-checkzone example.com /etc/bind/zones/db.example.com
sudo rndc reload example.com

Команда named-checkzone находит опечатки и нарушения формата до того, как они попадут в продакшен, а rndc reload подхватывает изменения без полного перезапуска службы и разрыва текущих сессий.

Вторичный сервер и передача зоны (AXFR)

Для отказоустойчивости нужен минимум один вторичный сервер на отдельном IP — это же требование лежит в основе glue-записей, если NS-серверы находятся внутри самого делегируемого домена. Конфигурация slave выглядит так:

zone "example.com" {
    type slave;
    file "/var/cache/bind/db.example.com";
    masters { 203.0.113.10; };
};

После первого успешного AXFR вторичный сервер хранит копию зоны локально и продолжает отвечать на запросы, даже если мастер временно недоступен. Проверить, что обе версии зоны совпадают, можно сверкой serial через dig, как описано в статье про проверку DNS-зоны. Если планируете делегировать часть пространства имён на отдельные NS, изучите также делегирование поддомена.

Итог: чек-лист запуска авторитативного сервера

named-checkconf и named-checkzone проходят без ошибок перед каждым reload.
Минимум два NS-сервера на разных IP и, желательно, в разных сетях.
allow-transfer ограничен конкретными IP вторичных серверов, а не открыт всем.
Serial увеличивается при любой правке зоны, а изменения сразу видны через dig с внешнего резолвера.

Свой DNS-сервер на BIND 9: авторитативная зона с нуля