Динамический DNS в BIND9: обновление A и AAAA через nsupdate и TSIG

Домены, DNS и почта
19 авг, 2026
Время на чтение: ~28 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GPT-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Dynamic DNS Update позволяет добавлять, заменять и удалять ресурсные записи специальными DNS-запросами, не редактируя файл зоны после каждой смены адреса. В BIND9 такие запросы отправляет утилита nsupdate, а для их аутентификации применяется TSIG — общий секрет, известный клиенту и авторитетному серверу.

Ниже рассматривается узкий сценарий: ключ ddns-home.example.net. сможет менять только записи A и AAAA имени home.example.net.. Он не получит доступа к MX, TXT, NS, SOA, другим именам или всей зоне. Это безопаснее широкого разрешения на обновление по IP-адресу либо правила, которое позволяет ключу изменять любые записи.

Инструкция рассчитана на VPS с root-доступом и уже работающим авторитетным BIND9. Домен example.net, адрес DNS-сервера, пути и имена служб в примерах необходимо заменить своими значениями.

Для самостоятельного авторитетного DNS требуется сервер с административным доступом: подойдёт VPS-сервер. На виртуальном хостинге, где нет доступа к конфигурации BIND и системным службам, эту настройку выполнить нельзя.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия

Нидерланды

Смотреть тарифы

Что потребуется перед настройкой

Убедитесь, что зона обслуживается этим сервером как первичная. Динамическое обновление принимает первичный сервер зоны, поэтому попытка отправить его вторичному серверу обычно завершается отказом.

Посмотреть SOA и указанный в нём первичный сервер можно командой:

dig example.net. SOA +short

Первое имя в записи SOA — значение MNAME. Если используется скрытый primary или особая топология DNS, фактический получатель обновлений может отличаться от публичного NS. В таком случае в nsupdate следует явно указать адрес сервера, принимающего UPDATE-запросы.

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

command -v named-checkconf
command -v named-checkzone
command -v tsig-keygen
command -v nsupdate
command -v dig
command -v rndc

Обычно они входят в серверные и клиентские пакеты BIND соответствующего дистрибутива. Установка BIND здесь не рассматривается, чтобы случайно не заменить уже работающую конфигурацию DNS.

В примерах используются следующие условные значения:

зона — example.net.;
изменяемое имя — home.example.net.;
имя TSIG-ключа — ddns-home.example.net.;
адрес первичного DNS-сервера — 192.0.2.53;
новый IPv4-адрес — 203.0.113.45;
новый IPv6-адрес — 2001:db8:100::45;
TTL динамических записей — 300 секунд.

Диапазоны адресов в примерах предназначены для документации и не маршрутизируются как обычные публичные сети. Подставьте реальные адреса. Если клиент находится за NAT, в A-запись обычно нужно помещать внешний адрес маршрутизатора, а не частный адрес вида 192.168.x.x. В AAAA указывают глобальный IPv6-адрес нужного узла, а не link-local адрес из диапазона fe80::/10.

Что потребуется перед настройкой

Шаг 1. Сделайте согласованную резервную копию

Перед изменением конфигурации сохраните файл с объявлением зоны, сам файл зоны и связанные включаемые файлы. Точные пути зависят от дистрибутива и текущей структуры BIND.

В Debian-based системах конфигурация часто находится в /etc/bind, а изменяемые данные зон удобно хранить в /var/lib/bind. В RHEL-based системах основной файл обычно расположен в /etc/named.conf, а зоны — под /var/named. Не переносите файлы только ради совпадения с примером, если текущая схема уже учитывает права, chroot, AppArmor или SELinux.

Если зона ещё не была динамической и рядом с её файлом нет журнала .jnl, достаточно скопировать конфигурацию и проверенный текстовый файл зоны. Пример для Debian-based системы:

stamp=$(date +%F-%H%M%S)
cp -a /etc/bind/named.conf.local "/root/named.conf.local.$stamp.bak"
cp -a /var/lib/bind/dynamic/example.net.zone "/root/example.net.zone.$stamp.bak"

Пример для RHEL-based системы:

stamp=$(date +%F-%H%M%S)
cp -a /etc/named.conf "/root/named.conf.$stamp.bak"
cp -a /var/named/dynamic/example.net.zone "/root/example.net.zone.$stamp.bak"

Если рядом с файлом зоны уже существует .jnl, зона ранее обновлялась динамически. В журнале могут находиться изменения, которых ещё нет в текстовом файле, поэтому копия одного файла .zone не является полной согласованной резервной копией.

Для получения согласованного текстового состояния временно заморозьте зону штатной командой BIND:

rndc freeze example.net.

Команда синхронизирует динамические изменения с файлом зоны и временно запрещает UPDATE-запросы для неё. Убедитесь, что команда завершилась успешно, после чего скопируйте файл зоны и конфигурацию. Для Debian-based системы:

stamp=$(date +%F-%H%M%S)
cp -a /etc/bind/named.conf.local "/root/named.conf.local.$stamp.bak"
cp -a /var/lib/bind/dynamic/example.net.zone "/root/example.net.zone.$stamp.bak"

Для RHEL-based системы:

stamp=$(date +%F-%H%M%S)
cp -a /etc/named.conf "/root/named.conf.$stamp.bak"
cp -a /var/named/dynamic/example.net.zone "/root/example.net.zone.$stamp.bak"

Сразу после копирования снова разрешите динамические обновления:

rndc thaw example.net.

Не оставляйте зону замороженной дольше необходимого: пока действует freeze, клиентские UPDATE-запросы будут отклоняться. Если заморозить зону нельзя, резервное копирование должно согласованно охватывать и файл зоны, и его журнал .jnl; простое последовательное копирование работающей изменяемой зоны может зафиксировать их в разных состояниях.

Если указанного файла нет, сначала найдите реальное объявление зоны:

grep -R 'zone "example.net"' /etc/bind /etc/named.conf /etc/named 2>/dev/null

Шаг 2. Проверьте расположение динамической зоны

После первого успешного обновления BIND создаёт рядом с файлом зоны бинарный журнал с расширением .jnl. Процесс named должен иметь право создавать файлы в соответствующем каталоге. Одного права на чтение файла зоны недостаточно: каталог также должен быть доступен для записи служебному пользователю BIND.

Debian-based системы

install -d -o bind -g bind -m 0750 /var/lib/bind/dynamic
chown bind:bind /var/lib/bind/dynamic/example.net.zone
chmod 0640 /var/lib/bind/dynamic/example.net.zone

RHEL-based системы

install -d -o named -g named -m 0750 /var/named/dynamic
chown named:named /var/named/dynamic/example.net.zone
chmod 0640 /var/named/dynamic/example.net.zone
restorecon -RFv /var/named/dynamic

Команды предполагают, что файл уже скопирован или перемещён в выбранный каталог. Если вы меняете путь, одновременно исправьте параметр file в объявлении зоны. На системе с chroot путь в конфигурации интерпретируется относительно корня окружения BIND, а при активных AppArmor или SELinux одних Unix-прав может быть недостаточно.

До включения динамических обновлений проверьте исходный файл. Для Debian-based варианта:

named-checkzone example.net. /var/lib/bind/dynamic/example.net.zone

Для RHEL-based варианта:

named-checkzone example.net. /var/named/dynamic/example.net.zone

Ожидаемый результат — сообщение об успешной загрузке зоны. Если проверка сообщает об ошибке синтаксиса, сначала исправьте её и только затем продолжайте.

Шаг 3. Создайте отдельный TSIG-ключ

Не используйте для DDNS ключ управления rndc или ключ другой интеграции. Отдельный секрет упрощает ограничение полномочий, отзыв доступа и расследование ошибок.

Debian-based системы

install -d -o root -g bind -m 0750 /etc/bind/keys
sh -c 'umask 077; tsig-keygen -a hmac-sha256 ddns-home.example.net. > /etc/bind/keys/ddns-home.key'
chown root:bind /etc/bind/keys/ddns-home.key
chmod 0640 /etc/bind/keys/ddns-home.key

RHEL-based системы

install -d -o root -g named -m 0750 /etc/named/keys
sh -c 'umask 077; tsig-keygen -a hmac-sha256 ddns-home.example.net. > /etc/named/keys/ddns-home.key'
chown root:named /etc/named/keys/ddns-home.key
chmod 0640 /etc/named/keys/ddns-home.key
restorecon -RFv /etc/named/keys

Утилита создаст конструкцию примерно следующего вида:

key "ddns-home.example.net." {
    algorithm hmac-sha256;
    secret "BASE64_SECRET";
};

Строка secret — это пароль к возможности обновления разрешённых записей. Не публикуйте файл, не добавляйте его в репозиторий и не вставляйте секрет в команды командной строки. Для nsupdate безопаснее параметр -k, читающий ключ из файла. Параметр -y передаёт секрет непосредственно в аргументе процесса, поэтому он может сохраниться в истории оболочки или быть видимым через список процессов.

Если обновление будет запускаться не на DNS-сервере, скопируйте ключ на доверенный клиент по защищённому каналу и ограничьте права:

install -o root -g root -m 0600 ddns-home.key /root/ddns-home.key

На клиенте root-доступ нужен не самому протоколу, а только для чтения ключа в этом примере. Можно создать отдельного системного пользователя, хранить ключ в закрытом для остальных каталоге и запускать задачу от его имени.

Если требуется выдавать сертификаты для поддоменов тем же подходом, пригодится инструкция по ACME DNS-01 wildcard через RFC2136 и TSIG.

Шаг 4. Подключите ключ к конфигурации BIND9

Добавьте директиву include на верхнем уровне конфигурации, вне блоков options и zone.

Debian-based системы

include "/etc/bind/keys/ddns-home.key";

RHEL-based системы

include "/etc/named/keys/ddns-home.key";

Не копируйте содержимое ключа непосредственно в общий файл конфигурации без необходимости. Отдельный файл позволяет настроить более строгие права и безопаснее переносить конфигурацию без секрета.

Шаг 5. Ограничьте обновления через update-policy

Найдите существующий блок первичной зоны и добавьте в него update-policy. Для Debian-based варианта он может выглядеть так:

zone "example.net" {
    type primary;
    file "/var/lib/bind/dynamic/example.net.zone";

    update-policy {
        grant ddns-home.example.net. name home.example.net. A AAAA;
    };
};

Для RHEL-based системы меняется главным образом путь:

zone "example.net" {
    type primary;
    file "/var/named/dynamic/example.net.zone";

    update-policy {
        grant ddns-home.example.net. name home.example.net. A AAAA;
    };
};

Элементы правила означают следующее:

grant — разрешить операцию при совпадении всех условий;
ddns-home.example.net. — identity, то есть полное имя TSIG-ключа, подписавшего запрос;
name — точное совпадение имени записи;
home.example.net. — единственное имя, доступное этому правилу;
A AAAA — разрешённые типы записей.

Точки в конце полных доменных имён лучше указывать явно. Они исключают неоднозначность относительно текущего origin конфигурации и помогают визуально отличить FQDN от относительного имени.

Если один доверенный клиент действительно должен обновлять два имени, добавьте второе точное правило:

update-policy {
    grant ddns-home.example.net. name home.example.net. A AAAA;
    grant ddns-home.example.net. name vpn.example.net. A AAAA;
};

Если имена принадлежат независимым устройствам или пользователям, безопаснее выдать отдельный ключ на каждое имя. Компрометация одного клиента тогда не позволит менять адрес другого.

Не заменяйте точные правила конструкцией вроде zonesub ANY без обоснованной необходимости. Такое разрешение даст ключу значительно больше полномочий, включая изменение других имён и типов записей.

В одном блоке зоны нельзя одновременно использовать allow-update и update-policy. Если ранее был настроен allow-update, удалите или закомментируйте его после проверки того, какие клиенты от него зависят.

Шаг 6. Проверьте конфигурацию и примените её безопасно

Сначала проверьте синтаксис без перезапуска службы:

named-checkconf

Если BIND запущен с нестандартным главным файлом, передайте его путь:

named-checkconf /etc/named.conf

Расширенная проверка с загрузкой первичных зон:

named-checkconf -z

Отдельно убедитесь, что служебный пользователь способен прочитать ключ и записать журнал в каталог зоны.

Debian-based системы

sudo -u bind test -r /etc/bind/keys/ddns-home.key
sudo -u bind test -w /var/lib/bind/dynamic

RHEL-based системы

sudo -u named test -r /etc/named/keys/ddns-home.key
sudo -u named test -w /var/named/dynamic

Если проверки завершились без вывода и вернули код 0, Unix-права подходят. Это не исключает блокировку со стороны SELinux, AppArmor или chroot, поэтому при проблемах также проверяйте системный журнал.

Примените конфигурацию без безусловного перезапуска DNS:

rndc reconfig
rndc zonestatus example.net.

Если rndc в этой установке не настроен, используйте штатную перезагрузку конфигурации службы: обычно systemctl reload bind9 в Debian-based системах или systemctl reload named в RHEL-based. Не выполняйте restart до проверки синтаксиса: остановка авторитетного DNS из-за опечатки затронет разрешение домена.

При ошибке верните резервную копию изменённого конфигурационного файла, снова выполните named-checkconf и повторите reload. Сообщения BIND доступны через журнал systemd:

journalctl -u bind9 -n 100 --no-pager
journalctl -u named -n 100 --no-pager

Используйте только команду, соответствующую реальному имени службы.

Шаг 7. Обновите A и AAAA через nsupdate

На сервере или клиенте, где находится копия ключа, создайте файл update-home.nsupdate:

server 192.0.2.53
zone example.net.
update delete home.example.net. A
update add home.example.net. 300 A 203.0.113.45
update delete home.example.net. AAAA
update add home.example.net. 300 AAAA 2001:db8:100::45
send
answer

Команда server направляет запрос конкретному авторитетному серверу. Использование IP-адреса исключает зависимость операции от разрешения имени самого NS. В рабочем файле укажите адрес первичного BIND9, принимающего обновления.

zone явно задаёт изменяемую зону. Без этой строки nsupdate пытается определить её самостоятельно, но явное значение упрощает диагностику и защищает сценарий от ошибочного выбора.

Сначала удаляется существующий RRset нужного типа, затем добавляется актуальное значение. Все строки до send отправляются одним UPDATE-запросом. Такой подход предотвращает накопление старых адресов, что особенно важно для A и AAAA: простое добавление новой записи не удаляет предыдущую.

Запустите обновление, указав файл ключа:

nsupdate -k /root/ddns-home.key update-home.nsupdate

Если ключ используется непосредственно на DNS-сервере Debian-based:

nsupdate -k /etc/bind/keys/ddns-home.key update-home.nsupdate

При успехе команда может завершиться без заметного сообщения. Строка answer помогает увидеть ответ сервера. Для подробной диагностики используйте режим отладки:

nsupdate -d -k /root/ddns-home.key update-home.nsupdate

Небольшие обновления обычно отправляются по UDP. Параметр -v принудительно включает TCP:

nsupdate -v -k /root/ddns-home.key update-home.nsupdate

DNS использует порт 53 по UDP и TCP. Если запрос идёт между разными узлами, проверьте существующие правила UFW, firewalld, nftables, сетевого экрана VPS и внешнего облачного firewall. Не устанавливайте новый firewall поверх действующего ради этой настройки. Публичный авторитетный DNS обычно уже должен принимать обычные запросы по обоим транспортам.

Как обновить только один тип адреса

Если IPv6 временно отсутствует, удалите старую AAAA без добавления новой:

server 192.0.2.53
zone example.net.
update delete home.example.net. AAAA
send
answer

Аналогично можно заменить только IPv4:

server 192.0.2.53
zone example.net.
update delete home.example.net. A
update add home.example.net. 300 A 203.0.113.45
send
answer

Не оставляйте устаревшую AAAA только потому, что сервис доступен по IPv4. Клиенты с IPv6 могут продолжать обращаться к старому адресу и получать ошибки, хотя A-запись уже обновлена.

Автоматизация обновления

nsupdate может читать команды из стандартного ввода, поэтому его удобно вызывать из локального сценария. Получение текущего публичного адреса зависит от сети, маршрутизатора и используемой схемы доступа и не относится к BIND9. Сценарий ниже предполагает, что корректные адреса уже переданы через переменные окружения:

#!/bin/sh
set -eu

SERVER="192.0.2.53"
ZONE="example.net."
NAME="home.example.net."
KEY="/root/ddns-home.key"
TTL="300"

: "${IPV4:?Set IPV4 before running}"
: "${IPV6:?Set IPV6 before running}"

nsupdate -k "$KEY" <<EOF
server $SERVER
zone $ZONE
update delete $NAME A
update add $NAME $TTL A $IPV4
update delete $NAME AAAA
update add $NAME $TTL AAAA $IPV6
send
answer
EOF

Запуск:

IPV4='203.0.113.45' IPV6='2001:db8:100::45' /usr/local/sbin/update-home-dns

Перед автоматизацией проверьте ручной запуск. Сам сценарий и файл ключа должны быть недоступны непривилегированным пользователям:

chown root:root /usr/local/sbin/update-home-dns /root/ddns-home.key
chmod 0700 /usr/local/sbin/update-home-dns
chmod 0600 /root/ddns-home.key

Если обновление запускается по таймеру systemd или cron, записывайте код завершения и диагностический вывод в журнал. Не запускайте запрос каждую секунду: обновление нужно отправлять при фактической смене адреса либо с разумным контрольным интервалом.

Шаг 8. Проверьте результат через dig

Сначала запросите записи непосредственно у обновлённого авторитетного сервера:

dig @192.0.2.53 home.example.net. A +noall +answer +comments
dig @192.0.2.53 home.example.net. AAAA +noall +answer +comments

В ответе должны присутствовать статус NOERROR, флаг aa и актуальная запись. Короткий вариант проверки:

dig @192.0.2.53 home.example.net. A +short
dig @192.0.2.53 home.example.net. AAAA +short

Затем проверьте остальные авторитетные серверы зоны, если они есть:

dig @ns2.example.net. home.example.net. A +short
dig @ns2.example.net. home.example.net. AAAA +short

Если вторичный сервер ещё показывает старое значение, проверьте SOA serial, передачу IXFR или AXFR, NOTIFY и журналы обоих серверов. Обновление следует отправлять первичному серверу, а не повторять вручную на каждой secondary-зоне.

В конце выполните запрос через обычный рекурсивный резолвер:

dig home.example.net. A +short
dig home.example.net. AAAA +short

Кэширующий резолвер может временно возвращать старое значение до истечения прежнего TTL. Прямой запрос к авторитетному серверу показывает состояние зоны без такого промежуточного кэша.

Проверьте, что ограничения действительно работают

Положительный тест подтверждает работоспособность ключа, но не доказывает правильность границ доступа. Выполните контролируемую попытку изменить неразрешённое имя:

nsupdate -k /root/ddns-home.key <<EOF
server 192.0.2.53
zone example.net.
update add forbidden.example.net. 300 A 203.0.113.99
send
answer
EOF

Сервер должен отклонить запрос, обычно со статусом REFUSED. Аналогично проверьте неразрешённый тип для разрешённого имени:

nsupdate -k /root/ddns-home.key <<EOF
server 192.0.2.53
zone example.net.
update add home.example.net. 300 TXT "must-not-be-added"
send
answer
EOF

TXT-запись не должна появиться. Проверьте это напрямую:

dig @192.0.2.53 home.example.net. TXT +noall +answer

Если отрицательный тест неожиданно прошёл, немедленно пересмотрите все правила update-policy и проверьте, нет ли другого широкого разрешения для того же ключа.

Типичные ошибки nsupdate

REFUSED

Сервер получил запрос, но политика не разрешила операцию. Проверьте точное совпадение имени TSIG-ключа в файле ключа и поля identity в update-policy, полные имена с точками, тип записи и имя владельца. Также убедитесь, что применяется изменённое объявление нужной зоны и нужный view.

NOTAUTH или NOTZONE

Запрос отправлен серверу, который не является авторитетным для зоны, указана неправильная зона либо изменяемое имя ей не принадлежит. Явно задайте правильные строки server и zone, затем проверьте SOA через dig.

BADKEY или BADSIG

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

BADTIME

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

SERVFAIL и ошибки создания журнала

Частая причина — процесс BIND не может создать .jnl рядом с файлом зоны. Проверьте владельца и права каталога, свободное место, режим файловой системы, chroot, AppArmor и SELinux. Смотрите журнал службы в момент отправки запроса.

Обновление принято, но файл зоны не изменился

Это не обязательно ошибка. Динамические изменения сначала сохраняются в бинарном журнале .jnl, а полный файл зоны обновляется сервером отдельно. Проверяйте текущее состояние через dig, а не только просмотром текстового файла.

При необходимости синхронизировать журнал с файлом зоны используйте:

rndc sync example.net.

Как редактировать динамическую зону вручную

После включения Dynamic DNS нельзя просто открыть исходный файл зоны и выполнить reload. В журнале могут находиться более свежие изменения, которые ещё не записаны в текстовый файл. Ручная правка без штатной остановки обновлений способна конфликтовать с журналом и привести к потере данных.

Если ручное изменение действительно необходимо, сначала заморозьте зону:

rndc freeze example.net.

BIND синхронизирует динамические изменения с файлом и временно отключит UPDATE для этой зоны. Только после успешного выполнения команды редактируйте фактический файл, указанный параметром file в объявлении зоны.

При ручном редактировании обязательно увеличьте SOA serial. Вторичные серверы сравнивают serial со своей копией зоны и могут не запросить перенос, если номер не изменился. Новый serial должен быть больше предыдущего с учётом правил 32-битной серийной арифметики DNS. Если используется распространённая схема YYYYMMDDNN, увеличьте суффикс NN для очередного изменения в тот же день, но сначала проверьте фактический формат текущей зоны.

После сохранения проверьте файл. Для Debian-based расположения из примеров:

named-checkzone example.net. /var/lib/bind/dynamic/example.net.zone

Для RHEL-based расположения:

named-checkzone example.net. /var/named/dynamic/example.net.zone

Если в параметре file указан другой путь, используйте именно его. Не выполняйте thaw, пока named-checkzone не подтвердит корректность файла. При ошибке верните исправный вариант из резервной копии либо устраните синтаксическую проблему, сохраняя serial больше номера, который был опубликован до ручного изменения.

После успешной проверки разморозьте зону:

rndc thaw example.net.

Затем убедитесь, что первичный сервер отдаёт новую версию зоны и увеличенный serial:

dig @192.0.2.53 example.net. SOA +noall +answer
dig @192.0.2.53 home.example.net. A +noall +answer
dig @192.0.2.53 home.example.net. AAAA +noall +answer

Если есть вторичные серверы, запросите SOA непосредственно у каждого из них и сравните serial:

dig @ns2.example.net. example.net. SOA +noall +answer

Не удаляйте .jnl вручную в попытке устранить проблему: сначала выясните состояние зоны и используйте штатные команды rndc.

Итоговая проверка

Рабочая настройка должна удовлетворять всем условиям:

Зона объявлена как type primary на сервере, принимающем обновление.
Каталог динамической зоны доступен процессу BIND для создания журнала.
Для DDNS создан отдельный TSIG-ключ с закрытыми правами.
Ключ подключён к конфигурации через include.
update-policy разрешает только нужные имена и типы A и AAAA.
named-checkconf и named-checkzone не сообщают об ошибках.
nsupdate -k успешно заменяет адреса на первичном сервере.
dig получает новые значения непосредственно от авторитетного DNS-сервера.
Попытки изменить другое имя или тип записи завершаются отказом.
При ручной правке динамической зоны используется rndc freeze, увеличивается SOA serial, проверяется фактический файл зоны и выполняется rndc thaw.

В результате адрес можно обновлять автоматически при его смене, не выдавая клиенту доступ ко всей зоне и не редактируя её файл при каждом изменении IPv4 или IPv6.

Поделиться статьей