Кратко

  • Ответ DNS NOTIFY означает, что вторичный сервер получил уведомление; полезных данных о содержимом зоны в нём нет.
  • Сравнение серийных номеров SOA, IXFR или AXFR, загрузка версии и авторитетные ответы образуют отдельные этапы доказательства.
  • Нужна квитанция публикации зоны, которая сохраняет каждый переход и не превращает уведомление в гарантию обслуживания.

Уведомление закрывает только свою транзакцию

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

Оно не сообщает текущий SOA вторичного сервера, решение о переносе, окончание передачи или поколение данных в отвечающем процессе. Спецификация прямо говорит, что ответ не содержит полезной информации. Поэтому зелёный статус NOTIFY относится к каналу уведомления, а не к публикации зоны.

После корректного SOA NOTIFY вторичный сервер действует как при завершении refresh: запрашивает SOA у известного мастера, сравнивает номера и начинает IXFR или AXFR, если удалённый номер продвинулся. Эти операции следуют за ответом.

Между передачей и выдачей остаётся граница

Необязательная секция ответа в NOTIFY является небезопасной подсказкой и не может обновлять локальные данные. RFC 1982 задаёт арифметику серийных номеров, включая расстояние, при котором сравнение не определено. Поэтому квитанция должна хранить оба значения и фактический результат сравнения.

IXFR переносит изменения, AXFR может перенести полную зону. RFC 5936 относит AXFR к механизмам согласования авторитетных серверов. Но завершение передачи не доказывает reload, активацию каждого процесса или сходимость всех узлов anycast.

Финальное наблюдение — прямой авторитетный запрос SOA и реально изменённого RRset к каждому NS и репрезентативным точкам. Рекурсивный кэш может законно хранить прежнее значение до истечения TTL и проверяется отдельно.

Источники