BIND9: зона не обновляется после изменения SOA serial

#Что произошло и как распознать неисправность

После изменения номера SOA serial администратор видит старые DNS-записи на вторичном сервере или сообщение об ошибке загрузки первичной зоны. Важно различать эти случаи: сам по себе уменьшенный или неизменённый serial обычно не является синтаксической ошибкой загрузки на primary, однако secondary может не принять обновление, считая его не новее. Неправильный формат файла, отсутствующий SOA или неподдерживаемая запись действительно способны помешать загрузке. Если файл проходит проверку, но secondary остаётся прежним, сравните serial на обеих сторонах и анализируйте передачу IXFR/AXFR; вычисление новизны описано в RFC 1982.

#Причины и отличительные признаки

#Пошаговая диагностика и исправление

1. Запишите исходные значения на каждом DNS-сервереВ терминале компьютера с dig выполните dig @ns1.example.com example.com SOA +short и аналогично запросите второй NS. Замените имена на реальные. В ответе после адреса администратора зоны идёт число serial; запишите его целиком. Если один узел не отвечает, сначала решайте проблему связи; если оба отвечают одним числом, но с разными A-записями, возможно неполное обновление кэша или другой view.
2. Убедитесь, что сравниваете primary и secondary нужной зоныВ панели управления или на сервере BIND найдите объявление zone "example.com" и type primary (в старых версиях master). Посмотрите путь file и какой экземпляр named обслуживает запрос. При нескольких views одна зона может быть объявлена с разными файлами. Не редактируйте первую попавшуюся копию, пока не установили её соответствие DNS-ответу.
3. Проверьте синтаксис именно указанного файлаПо SSH на основном сервере выполните sudo named-checkzone example.com /etc/bind/db.example.com, заменив имя и путь реальными значениями из конфигурации. OK означает, что файл зоны пригоден для загрузки в условиях этой проверки, но не доказывает её обновление у secondary. Если появилась ошибка SOA или строки, исправьте указанную запись в копии и повторите проверку.
4. Посмотрите, не ведёт ли BIND динамический журналВ конфигурации проверьте наличие allow-update, update-policy, inline-signing и файла .jnl рядом с зоной. При динамической зоне нельзя просто удалить .jnl ради «перезагрузки». Администратор должен использовать поддерживаемый rndc freeze/rndc thaw при необходимости ручной правки либо механизм DNS UPDATE; сохраняйте копии и учитывайте активный DNSSEC.
5. Сравните номера serial с правилами RFC 1982Если primary имеет 2026110201, а secondary 2026110301, вторичный сервер считает исходное значение устаревшим. Внесите реальную, согласованную правку в основной источник и задайте serial новее текущего у secondary с учётом модульной арифметики 32 бит. Не ставьте произвольное огромное число: это может затруднить будущие обновления. При переполнении или нестандартной последовательности согласуйте процедуру со специалистом.
6. Проверьте конфигурацию и перечитайте изменённую зонуСоздайте резервную копию исходной зоны и конфигурации. Выполните на primary sudo named-checkconf -z. Если ошибок нет, используйте sudo rndc reload example.com, чтобы перечитать указанную зону, а не перезапускать весь DNS без необходимости. Если rndc не подключается к службе, проверьте конфигурацию управления и права доступа; не переносите ключ rndc на клиентский компьютер.
7. Проверьте обновление secondary и причины задержкиСпустя короткое время запросите SOA обоих NS повторно. Если secondary старый, проверьте журнал на secondary через sudo journalctl -u bind9 -n 100 --no-pager; при несовпадающем имени службы примените named. При transfer failed проверьте IP источника, правила передачи allow-transfer и соединение TCP/53. Нельзя открывать AXFR всему интернету ради диагностики.
8. Сверьте записи и предусмотрите откатСравните A, AAAA и NS на primary и secondary командой dig @сервер имя тип +short для нескольких контрольных имён. Запишите время и serial. Если ошибка в ваших изменениях, восстановите сохранённый файл и установите корректный новый serial, чтобы secondary действительно получил восстановленную версию: простое возвращение старого меньшего числа не всегда сработает.
9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Проверка файла зоны на сервере без изменений.

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Проверка файла зоны на сервере без изменений. Укажите существующий путь и имя зоны; пример Debian, нужен sudo при ограниченном доступе.

   sudo named-checkzone example.com /etc/bind/db.example.com

   Вариант 2Пробная загрузка всех первичных зон, без перезапуска.

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Пробная загрузка всех первичных зон, без перезапуска. Права sudo.

   sudo named-checkconf -z

   Вариант 3После сохранения копии и успешной проверки: штатная перечитка заданной зоны.

   Linux · Терминал (Bash)С осторожностьюНужен sudoКопировать всёВыделить

   После сохранения копии и успешной проверки: штатная перечитка заданной зоны. Замените домен, права sudo; влияет на обслуживаемую зону.

   sudo rndc reload example.com

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

#Как проверить результат и что делать при неуспехе

Результат подтверждён только тогда, когда SOA serial и содержимое контрольных записей совпадают на всех авторитетных NS. Если named-checkzone показывает OK, но обновления нет — ищите журналы передачи, а не «ошибку serial при загрузке».