#Что произошло и как распознать неисправность
На основном DNS-сервере появились новые A, MX или TXT-записи, но вторичный BIND9 отдаёт прежний результат. Служба secondary работает, однако SOA serial отстаёт либо совпадает при несовпадающих данных. Это проблема передачи зоны или порядка обновления, а не обязательно кеш браузера. Перед исправлением сравните авторитетные SOA у обоих серверов и отдельно посмотрите TCP/53, разрешение transfer, NOTIFY и IP источника. Нельзя открывать копирование зоны для всех адресов, чтобы временно убрать ошибку.
#Причины и отличительные признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| У primary не увеличен SOA serialНовая запись сохранена в редакторе, но зона не получила нового серийного номера. | Primary и secondary имеют одинаковый serial, однако данные различаются. | Выполнить корректное обновление и увеличить serial. |
Запрещён AXFR/IXFRВ allow-transfer нет IP вторичного сервера или не совпадает ключ TSIG. | В журнале transfer failed, REFUSED или TSIG error. | Разрешить передачу только известному secondary. |
| Нет связи TCP/53UDP запросы работают, передача по TCP фильтруется на маршруте. | dig +tcp к primary с secondary не получает ответа. | Проверить межсетевой экран и маршруты для конкретной пары серверов. |
| NOTIFY не приходитОжидание обновления зависит от SOA REFRESH, а адрес secondary не настроен в оповещениях. | После изменения primary зона обновляется лишь спустя время или вручную. | Проверить notify, also-notify и разрешённых отправителей. |
#Пошаговая диагностика и исправление
- Сравните SOA на обоих серверахС компьютера с
digвыполнитеdig @ns1.example.com example.com SOA +shortиdig @ns2.example.com example.com SOA +short. Замените имена на реальные, прочитайте число serial в каждом ответе. Если serial одинаковый, но запись различается, проверьте что запросы действительно доходят до нужных серверов и не попадают в разные view. - Уточните, где находится основной источник зоныНа основном Linux-сервере откройте через SSH конфигурацию нужной зоны и найдите
type primary,file,notify. На вторичном сервере —type secondaryиprimaries(или староеmasters). Проверьте фактические IP, учёт IPv4/IPv6 и сетевую доступность. Не меняйте роль сервера в конфигурации без согласованной схемы делегирования. - Проверьте доступность primary по TCP/53В терминале secondary выполните
dig +tcp @192.0.2.10 example.com SOA, заменяя IP реальным primary. Успешный SOA через TCP подтверждает возможность обычного DNS-соединения TCP, но не разрешение копирования всей зоны. Если тайм-аут — проверьте firewall, NAT, маршрут и то, что named слушает нужный адрес; не открывайте TCP/53 всем источникам без необходимости. - Прочитайте сообщения о transfer и NOTIFYНа secondary по SSH запустите
sudo journalctl -u bind9 -n 100 --no-pager, а если служба именуетсяnamed, измените имя. Ищите строкиtransfer,not authoritative,refused,notifiesиTSIG. Запишите время и IP. Отказ может исходить изallow-transferна primary, отсутствующей зоны или неверного ключа, а не из настроек локального кеша. - Проверьте передачу только к доверенному адресуНа primary просмотрите
allow-transferвнутри нужной zone/view; с BIND9 новых выпусков по умолчанию передача может быть закрыта. При подтверждённом отказе внесите IP secondary или соответствующий ключ TSIG в список разрешений, сохраните копию файла и выполнитеsudo named-checkconf. Не используйтеallow-transfer { any; };на публичном сервере. - Проверьте serial и оповещенияЗапросите SOA у primary после внесения новой записи. Если номер не вырос, первичный сервер не уведомит secondary о новой версии; исправьте serial исходной зоны. При сложной схеме проверьте
notifyиalso-notify, а на secondaryallow-notify. Отсутствие NOTIFY не всегда блокирует обновление навсегда: BIND также опрашивает по SOA refresh. - Примените настройки и запросите обновлениеПосле резервной копии и успешной проверки синтаксиса перечитайте настройки нужного сервера командой
sudo rndc reconfigили обновлённую основную зонуsudo rndc reload example.com. На secondary при исправленной доступности допустимsudo rndc refresh example.com, который запрашивает состояние зоны у primary. Если rndc показывает ошибку, не редактируйте секреты TSIG по совету случайного сайта. - Подтвердите совпадение данных и безопасный откатПовторно сравните SOA serial и значения изменённых записей при прямых запросах к каждому NS. Если переправка не работает, верните исходную конфигурацию по резервной копии, проверьте синтаксис и перечитайте её; запишите журнал и адреса серверов для диагностики. Не стирайте локальную копию secondary-зоны для принуждения к передаче: она может быть единственной доступной копией.
- Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Как проверить результат и что делать при неуспехе
Ожидаемый результат — одинаковый свежий SOA serial и идентичные контрольные записи на primary и secondary. Если журнал сообщает REFUSED/TSIG, остановите повторные попытки и согласуйте точные ограничения перед передачей.