BIND9 на Ubuntu 24.04: пошаговая установка

MAATRIX

Готовые DNS-хостинги удобны, пока вам не нужны нестандартные записи, собственная зона для внутренней сети или полный контроль над тем, что и кому сервер отдаёт в ответ. BIND9 — тот самый DNS-сервер, на котором десятилетиями держится половина интернета: сложный на вид, но предсказуемый и документированный вдоль и поперёк. Разберём установку на Ubuntu 24.04 с нуля — от пакета до рабочей авторитетной зоны с проверкой синтаксиса на каждом шаге.

Авторитетный или рекурсивный: с чем вы имеете дело

BIND9 умеет играть две разные роли, и путать их — источник половины проблем у новичков. Авторитетный сервер хранит зону вашего домена и отвечает на вопросы о ней: «какой IP у mydomain.ru» — данные берутся из локального файла зоны, сервер ничего не запрашивает у других. Рекурсивный (кэширующий) сервер, наоборот, не владеет никакими зонами — он получает вопрос от клиента, сам обходит цепочку DNS от корневых серверов до нужного домена и возвращает ответ, попутно кэшируя его.

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

Типичные задачи для BIND9 на арендованном сервере: собственный авторитетный DNS для доменов без привязки к регистратору, внутренний DNS для резолва хостов по коротким именам в приватной сети, тестовый стенд для отладки зон перед переносом на прод. Для «просто быстрого DNS для VPN» часто хватает и более лёгких решений, но там, где важны предсказуемость поведения, DNSSEC и промышленные практики — BIND9 остаётся стандартом де-факто.

Шаг 1. Установка пакета

На Ubuntu 24.04 BIND9 ставится из стандартных репозиториев вместе с утилитами администрирования:

apt update
apt install -y bind9 bind9utils bind9-dnsutils
systemctl status bind9

Пакет bind9utils даёт инструменты named-checkconf и named-checkzone для проверки конфигурации до перезапуска сервиса — ими нужно пользоваться после каждой правки, не полагаясь на то, что «и так заработает». Пакет bind9-dnsutils добавляет dig и nslookup, без которых тестировать зону будет неудобно.

После установки сервис уже запущен и слушает порт 53, но работает в режиме резолвера по умолчанию — без ваших зон и без ограничений на то, кто может им пользоваться. Следующие шаги приводят конфигурацию к рабочему и безопасному виду.

ss -lntup | grep :53
named -v

Первая команда покажет, что named слушает 53/tcp и 53/udp, вторая — установленную версию BIND. На момент актуальности статьи в репозиториях Ubuntu 24.04 идёт актуальная ветка BIND 9.18 — версия обновляется вместе с пакетами системы, точный номер уточняйте у named -v на своём сервере.

Шаг 2. Структура конфигурации

BIND9 в Ubuntu разносит конфигурацию по нескольким файлам в /etc/bind/, и это не случайность, а удобная организация:

• named.conf — главный файл, просто подключает остальные через include;
• named.conf.options — глобальные настройки: рекурсия, слушаемые адреса, форвардинг;
• named.conf.local — объявления ваших зон;
• named.conf.default-zones — служебные зоны (localhost, обратная зона 127.0.0.0/8) — трогать не нужно.

Такое разделение упрощает жизнь: вы правите options и local, а системные настройки остаются нетронутыми и не мешаются под руками. Посмотреть текущее состояние:

cat /etc/bind/named.conf
ls -la /etc/bind/

Файлы самих зон принято хранить в /etc/bind/zones/ — этой директории по умолчанию нет, создайте её сами:

mkdir -p /etc/bind/zones
chown root:bind /etc/bind/zones

Шаг 3. Настраиваем глобальные опции

Откройте named.conf.options и задайте базовые параметры — интерфейсы, на которых слушать, и явное ограничение рекурсии, если сервер должен быть только авторитетным:

nano /etc/bind/named.conf.options

acl "trusted" {
    127.0.0.1;
    10.0.0.0/8;         // ваша приватная сеть, если есть
};

options {
    directory "/var/cache/bind";

    listen-on { any; };
    listen-on-v6 { any; };

    // Рекурсия только для доверенных сетей.
    // Для чисто авторитетного сервера — recursion no;
    recursion yes;
    allow-recursion { trusted; };

    allow-query { any; };
    allow-transfer { none; };   // запрещаем зональные трансферы по умолчанию

    dnssec-validation auto;

    version "unknown";          // не светим версию BIND наружу
};

Ключевая строка — allow-recursion { trusted; }. Она разделяет два режима, о которых шла речь выше: клиенты из вашей сети получают полноценный рекурсивный резолв, а посторонние из интернета — только ответы по зонам, которые сервер реально обслуживает как авторитетный. Без этого ограничения открытый резолвер рано или поздно попадёт в список для DNS-амплификации, и его начнут использовать в чужих атаках — совсем не то, ради чего вы его поднимали.

allow-transfer { none; } закрывает передачу зоны (AXFR) всем подряд — включите её точечно только для конкретных slave-серверов, если такие есть.

Шаг 4. Создаём авторитетную зону

Предположим, домен — example-lab.ru, а сервер отдаёт для него A-записи. Объявляем зону в named.conf.local:

nano /etc/bind/named.conf.local

zone "example-lab.ru" {
    type master;
    file "/etc/bind/zones/db.example-lab.ru";
    allow-transfer { 203.0.113.20; };  // IP вторичного NS, если есть
};

Теперь создаём сам файл зоны на основе стандартного шаблона:

cp /etc/bind/db.local /etc/bind/zones/db.example-lab.ru
nano /etc/bind/zones/db.example-lab.ru

$TTL    3600
@       IN      SOA     ns1.example-lab.ru. admin.example-lab.ru. (
                        2026090101      ; Serial (год-месяц-день-номер)
                        3600            ; Refresh
                        900             ; Retry
                        604800          ; Expire
                        3600 )          ; Negative TTL

; Записи NS
@       IN      NS      ns1.example-lab.ru.

; A-записи
@       IN      A       203.0.113.10
ns1     IN      A       203.0.113.10
www     IN      A       203.0.113.10
mail    IN      A       203.0.113.11

; MX и вспомогательные записи
@       IN      MX      10 mail.example-lab.ru.
@       IN      TXT     "v=spf1 mx ~all"

Серийный номер (Serial) — не декоративное поле. Вторичные серверы и кэши сверяют его, чтобы понять, обновилась ли зона. Формат ГГГГММДДNN — стандартная практика: при любой правке зоны увеличивайте номер, иначе изменения не разъедутся дальше вашего сервера. Забытый серийный номер — вторая по частоте причина «я поправил запись, а она не обновляется» после проблем с кэшированием у клиентов.

Шаг 5. Обратная зона и проверка синтаксиса

Прямая зона отвечает на вопрос «какой IP у имени», обратная — на обратный: «какое имя у IP» (PTR-запись). Она нужна для полноценной работы почты и части сетевых проверок. Для сети 203.0.113.0/24 зона объявляется в named.conf.local:

zone "113.0.203.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.203.0.113";
};

Файл зоны:

$TTL    3600
@       IN      SOA     ns1.example-lab.ru. admin.example-lab.ru. (
                        2026090101
                        3600
                        900
                        604800
                        3600 )

@       IN      NS      ns1.example-lab.ru.

10      IN      PTR     example-lab.ru.
11      IN      PTR     mail.example-lab.ru.

Обратите внимание: реальный контроль над PTR-записью для арендованного сервера обычно остаётся у провайдера, который выдал IP — именно он владеет обратной зоной этой подсети. Локальная запись в вашем BIND полезна для внутренних нужд, но для внешнего мира авторитетным по-прежнему будет ответ провайдера, если он не делегировал вам зону явно.

Перед перезапуском проверяйте синтаксис — это должно войти в привычку после любой правки:

named-checkconf
named-checkzone example-lab.ru /etc/bind/zones/db.example-lab.ru
named-checkzone 113.0.203.in-addr.arpa /etc/bind/zones/db.203.0.113

named-checkconf без вывода означает, что конфигурация синтаксически верна. named-checkzone должен вывести OK — если видите ошибку, BIND укажет строку файла зоны, где проблема, чаще всего это забытая точка в конце FQDN-записи или несовпадающий серийный номер.

Шаг 6. Применяем, управляем через rndc и защищаем сервис

Применить настройки можно перезапуском сервиса, но для рабочего сервера правильнее пользоваться rndc — управляющей утилитой BIND, которая умеет перечитывать конфигурацию и зоны без разрыва уже установленных соединений:

systemctl restart bind9
rndc reload
rndc status

rndc reload перечитывает и конфигурацию, и все зоны — удобно после правки записей без падения сервиса. Если менялась только одна зона, точечнее и быстрее сработает rndc reload example-lab.ru.

Из практических мер защиты, кроме уже заданных ACL на рекурсию и трансфер зон:

• заблокируйте порт 53 фаерволом для всех, кому DNS не нужен — если уже настроен UFW на Ubuntu 24.04, откройте 53/tcp и 53/udp только для нужных сетей, а не для any;
• держите version "unknown"; в опциях — не защита сама по себе, но убирает бесплатную подсказку сканерам о версии сервера;
• логируйте запросы отдельным каналом при расследовании аномалий:

logging {
    channel query_log {
        file "/var/log/bind/query.log" versions 5 size 20m;
        severity info;
        print-time yes;
    };
    category queries { query_log; };
};

Не забудьте создать директорию и права для лога (mkdir -p /var/log/bind && chown bind:bind /var/log/bind), иначе BIND не сможет писать и упадёт при старте с этой секцией. Постоянное логирование всех запросов грузит диск на высоконагруженном резолвере — включайте его точечно, для диагностики, и выключайте после.

Шаг 7. DNSSEC и текущее обслуживание

dnssec-validation auto;, заданный в шаге 3, включает проверку подписей DNSSEC для зон, которые её поддерживают — это защищает клиентов вашего резолвера от подмены ответов на пути. Подписать собственную авторитетную зону DNSSEC-ключами — отдельная задача (генерация KSK/ZSK, ротация, публикация DS-записи у регистратора), и для учебных и внутренних сценариев она не обязательна с первого дня. Валидацию входящих ответов включайте сразу, подпись своей зоны — когда домен стабилизируется в продакшене.

Текущее обслуживание сводится к нескольким привычкам:

systemctl is-enabled bind9      # автозапуск после перезагрузки
dig @localhost example-lab.ru A
dig @203.0.113.10 www.example-lab.ru +short
journalctl -u bind9 -f          # логи сервиса в реальном времени

Первая команда для сети, вторая и третья — проверка ответов сервера напрямую, без промежуточных кэшей. Раз в несколько недель заглядывайте в rndc status, чтобы видеть число обслуженных зон и активность резолвера, и не забывайте бэкапить каталог /etc/bind/zones/ вместе с остальной конфигурацией сервера.

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