Настройка DNS-сервера BIND9 на Linux для внутренней сети

Если в вашей инфраструктуре больше 5–10 серверов, resolving через публичные DNS замедляет развёртывание и создаёт зависимость от интернет-канала. Собственный DNS-сервер на BIND9 решает обе проблемы: быстрое разрешение внутренних имён и полный контроль над зонами.

Среда: Ubuntu 22.04 LTS, BIND9 версия 9.18, внутренняя сеть 192.168.10.0/24, домен corp.local.

1. Установка BIND9

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

# Проверяем версию
named -v
# BIND 9.18.28-0ubuntu0.22.04.1 (Extended Support Version)

# Проверяем статус сервиса
sudo systemctl status bind9

Конфигурационные файлы лежат в /etc/bind/:

named.conf - точка входа, подключает остальные файлы
named.conf.options - глобальные параметры (рекурсия, форвардеры, ACL)
named.conf.local - описания зон
db.* - файлы зон

2. Настройка глобальных параметров (named.conf.options)

Открываем файл:

sudo nano /etc/bind/named.conf.options

Базовая конфигурация для внутреннего DNS-сервера:

acl "trusted" {
    192.168.10.0/24;
    127.0.0.1;
};

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

    // Разрешаем рекурсию только для доверенных клиентов
    recursion yes;
    allow-recursion { trusted; };

    // Форвардеры - внешние DNS для запросов вне наших зон
    forwarders {
        8.8.8.8;
        1.1.1.1;
    };
    forward only;

    // Запрещаем запросы AXFR извне
    allow-transfer { none; };

    // Скрываем версию BIND от публичного доступа
    version "not disclosed";

    listen-on { 127.0.0.1; 192.168.10.1; };
    listen-on-v6 { none; };

    dnssec-validation auto;
};

Ключевой момент - блок acl "trusted". Без него любой хост в интернете сможет использовать ваш сервер как открытый резолвер, что приводит к участию в DNS-amplification атаках.

3. Создание прямой зоны (forward zone)

Прямая зона преобразует имена хостов в IP-адреса. Добавляем зону в named.conf.local:

sudo nano /etc/bind/named.conf.local

zone "corp.local" {
    type master;
    file "/etc/bind/db.corp.local";
    allow-query { trusted; };
};

Создаём файл зоны:

sudo cp /etc/bind/db.local /etc/bind/db.corp.local
sudo nano /etc/bind/db.corp.local

$TTL    604800
@       IN      SOA     ns1.corp.local. admin.corp.local. (
                         2026052201     ; Serial (формат YYYYMMDDNN)
                         3600           ; Refresh
                         1800           ; Retry
                         604800         ; Expire
                         86400 )        ; Negative Cache TTL
;
; Name servers
@       IN      NS      ns1.corp.local.

; A records
ns1     IN      A       192.168.10.1
web01   IN      A       192.168.10.10
web02   IN      A       192.168.10.11
db01    IN      A       192.168.10.20
gitlab  IN      A       192.168.10.30

; CNAME records
git     IN      CNAME   gitlab.corp.local.

Serial в формате YYYYMMDDNN нужно увеличивать при каждом изменении зоны, иначе вторичные DNS-серверы не получат обновления.

4. Создание обратной зоны (reverse zone)

Обратная зона преобразует IP в имена хостов. Нужна для корректной работы PTR-запросов и ряда почтовых серверов.

sudo nano /etc/bind/named.conf.local

Добавляем:

zone "10.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192.168.10";
    allow-query { trusted; };
};

Создаём файл обратной зоны:

sudo nano /etc/bind/db.192.168.10

$TTL    604800
@       IN      SOA     ns1.corp.local. admin.corp.local. (
                         2026052201
                         3600
                         1800
                         604800
                         86400 )
;
@       IN      NS      ns1.corp.local.

; PTR records - только последний октет IP
1       IN      PTR     ns1.corp.local.
10      IN      PTR     web01.corp.local.
11      IN      PTR     web02.corp.local.
20      IN      PTR     db01.corp.local.
30      IN      PTR     gitlab.corp.local.

5. Проверка конфигурации и перезапуск

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

# Проверка основного конфига
sudo named-checkconf

# Проверка файла прямой зоны
sudo named-checkzone corp.local /etc/bind/db.corp.local

# Проверка файла обратной зоны
sudo named-checkzone 10.168.192.in-addr.arpa /etc/bind/db.192.168.10

Если named-checkconf ничего не вывел - конфиг синтаксически корректен. named-checkzone должен завершиться строкой OK.

sudo systemctl restart bind9
sudo systemctl status bind9

6. Проверка через dig

# Прямой запрос - имя в IP
dig @192.168.10.1 web01.corp.local A

# Обратный запрос - IP в имя
dig @192.168.10.1 -x 192.168.10.10

# Проверка рекурсии (внешний домен)
dig @192.168.10.1 github.com

# Проверка, что от неизвестных хостов рекурсия запрещена
# (выполнить с хоста вне ACL trusted)
dig @192.168.10.1 github.com
# Должен вернуть: status: REFUSED

dig удобнее nslookup, потому что явно показывает TTL, флаги ответа и сервер, который обработал запрос. В строке flags: ищите qr aa rd ra для авторитетных ответов вашего сервера.

7. Настройка клиентов

На клиентских машинах сети 192.168.10.0/24 укажите IP вашего DNS-сервера:

# Временно (Ubuntu с systemd-resolved)
sudo resolvectl dns eth0 192.168.10.1
sudo resolvectl domain eth0 corp.local

# Постоянно через Netplan
# /etc/netplan/50-cloud-init.yaml
nameservers:
  addresses: [192.168.10.1]
  search: [corp.local]

После этого клиент может обращаться к хостам по коротким именам: ssh web01 вместо ssh web01.corp.local.

Итог

BIND9 на Ubuntu 22.04 настраивается за 30–40 минут. Основные точки ошибок: неправильный serial в файле зоны (не обновляется при изменениях), отсутствие ACL (сервер становится открытым резолвером), и блокировка рекурсии для внутренних клиентов. Проверяйте конфиг через named-checkconf и named-checkzone перед каждым перезапуском - это экономит время на диагностику. Для production-среды добавьте второй DNS-сервер с type slave и репликацией зон через AXFR с ограничением по IP.