Коли є сенс тримати власний 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: авторитативна зона з нуля