Bind — настройка вторичной (slave) зоны

Олег

26 февраля 2026

Считаем что перед настройкой зоны мы установили и настроили сервер Bind. Работаем в Debian 11.

Зона DNS — это определенная часть пространства имен DNS, размещенного на DNS-сервере. Зона DNS содержит записи ресурсов, а DNS-сервер отвечает на запросы записей в этом пространстве имен.

Пусть у нашего основного (master) DNS сервера будет IP 1.2.3.4. Первичную зону настроили:

Bind — настройка первичной (master) зоны

Аналогично разворачиваем второй DNS сервер. У вторичного (slave) DNS сервера будет IP 1.2.3.5.

Подготовка

Для того, чтобы вторичный сервер мог скачивать зоны, понадобится разрешить на обоих серверах порт TCP 53.

ufw allow 53/tcp

Если не используется ufw, можно влезть в iptables:

iptables -I INPUT 1 -p tcp --dport 53 -j ACCEPT

Сохранить правила можно с помощью iptables-persistent:

apt install iptables-persistent
netfilter-persistent save

Настройка вторичной зоны

Рассмотрим настройку первичной зона DNS, она же slave-зона, она же резервная зона.

Редактируем /etc/bind/named.conf.local, добавляем настройки для зоны:

zone "example.com" {
       type slave;
       file "/etc/bind/zones/db.example.com";
       masters { 1.2.3.4; };
       allow-query { any; };
};

example.com — Имя первичной зоны, которую будет обслуживать DNS-сервер. Это наш домен.
type — Тип зоны. Поскольку мы настраиваем вторичную зону, то тип: slave. Другие возможные типы: master, stub, forward.
Master — первичная зона, её и настраиваем. DNS-сервер, на котором размещена основная зона, является основным источником для получения сведений об этой зоне.
Slave — вторичная зона. Вторичная зона — это копия только для чтения, первичной зоны. Если зона, на котором размещается этот DNS-сервер, является вторичной зоной, этот DNS-сервер является вторичным источником для получения сведений об этой зоне. Зона на этом сервере должна быть получена с другого удаленного компьютера DNS-сервера, на котором также размещена зона.
Stub — зона заглушки. Зона заглушки содержит только сведения о доверенных серверах имен для зоны.
Forward — служит для перенаправления DNS-запросов определенной зоны на определенный DNS-сервер.
file — Путь к файлу с записями зоны. В отличие от master (где администратор правит этот файл вручную), здесь BIND сам записывает в этот файл данные, полученные от master-сервера.
masters — IP адрес первичного DNS-сервера. Эта директива говорит вторичному серверу, откуда брать копию зоны. Вторичный сервер будет периодически обращаться по этому адресу и спрашивать: "Не обновилась ли зона example.com?" (проверка серийного номера в SOA записи). Здесь могут быть и дополнительные параметры.
allow-query — Кому разрешено выполнять запросы. Данный параметр можно указать и в named.conf.options.

Перечитываем конфиг службы:

systemctl reload bind9

Настройка TSIG

TSIG (Transaction SIGnature — подписи транзакций) — это механизм аутентификации DNS-сообщений, первоначально описанный в RFC 2845. Он позволяет криптографически подписывать DNS-сообщения с использованием общего секретного ключа. TSIG может использоваться в любых DNS-транзакциях: для ограничения доступа к определенным функциям сервера (например, к рекурсивным запросам) только для авторизованных клиентов, когда контроль доступа на основе IP-адресов недостаточен или требует переопределения, а также для обеспечения подлинности сообщений, когда это критически важно для целостности сервера, например, при динамических обновлениях (UPDATE) или передаче зон с первичного (primary) сервера на вторичный (secondary).

Ключи TSIG можно создать с помощью команды tsig-keygen. Результатом ее работы является директива key, готовая для включения в файл named.conf. Имя ключа, алгоритм и размер можно задать параметрами командной строки; по умолчанию используются имя tsig-key, алгоритм HMAC-SHA256 и размер 256 бит соответственно.

Сгенерируем ключ с названием "transfer-key" используя алгоритм шифрования HMAC-SHA256:

tsig-keygen -a hmac-sha256 transfer-key

Получим нечто подобное:

key "transfer-key" {
  algorithm hmac-sha256;
  secret "Y2b40sL16QalZLqYZqkDU5N9IW/H1pACqSwIcCwoNLM=";
};

В named.conf.options на обоих серверах (master и slave) под директивой options добавляем эту секцию:

options {
       // *** здесь ваши настройки
};
// добавляем сгенерированный TSIG ключ
key "transfer-key" {
  algorithm hmac-sha256;
  secret "Y2b40sL16QalZLqYZqkDU5N9IW/H1pACqSwIcCwoNLM=";
};
// *** другие настройки

Имя ключа и секрет (secret) должны быть идентичны на обоих хостах.

Поскольку этот текст содержит секрет, рекомендуется либо сделать файл named.conf.options недоступным для чтения всем пользователям, либо хранить директиву key в отдельном файле, который не доступен для чтения всем, и подключать его в named.conf с помощью директивы include.

На master

Редактируем /etc/bind/named.conf.local, добавляем TSIG ключ в секции masters:

zone "example.com" {
       type master;
       file "/etc/bind/zones/db.example.com";
       allow-transfer { 1.2.3.5; key "transfer-key"; };
       allow-update { none; };
       allow-query { any; };
};

Когда всё заработает, можно IP адрес сервера slave убрать и оставить только ключ.

На slave

Редактируем /etc/bind/named.conf.local, добавляем TSIG ключ в секции allow-transfer:

zone "example.com" {
       type slave;
       file "/etc/bind/zones/db.example.com";
       masters { 1.2.3.4 key "transfer-key"; };
       allow-query { any; };
};

Заключение

На обоих серверах:

systemctl reload bind9

На вторичном сервере должен появиться файл /etc/bind/zones/db.example.com. Естественно, в указанную папку должен иметь право писать пользователь bind. Можно просто сохранять файл зоны в /var/cache/bind/db.example.com, там уже должны быть нужные права.