DNS NOTIFY: проверка зоны после уведомления

Практическое пояснение: ответ на NOTIFY полезен как подтверждение получения уведомления, но в проверке синхронизации нужны также результат запроса SOA и завершение передачи зоны, если версия изменилась.

1. 01

   В RFC 1996 master — авторитетный сервер, настроенный как источник передачи зоны, а primary master находится в корне этой зависимости и указан в SOA MNAME. По умолчанию Notify Set содержит серверы из NS зоны, кроме указанного в SOA MNAME; скрытый сервер без NS может требовать явного добавления.

   Граница применимости: RFC 1996, август 1996 года; раздел 2.1, стр. 2. Термины приведены в области документа 1996 года. Администратор может изменить набор; отсутствие имени в NS не доказывает отсутствие серверной копии.

2. 02

   В графе зависимостей передачи зоны должен быть один primary master. Остальные серверы получают зону от него или от промежуточного сервера, который сам получает копию и служит источником для других. Циклы в графе AXFR не допускаются.

   Граница применимости: RFC 1996, август 1996 года; раздел 2.2, стр. 2. Речь о зависимостях передачи конкретной зоны, а не о маршрутах IP или запрете нескольких адресов у сервера.

3. 03

   Секция Answer запроса NOTIFY является незащищённой подсказкой. Её нельзя использовать для изменения локальной зоны, решения о начале передачи или изменения таймеров обновления. Совпавшая с локальными данными подсказка может позволить получателю не выполнять дальнейшую проверку.

   Граница применимости: RFC 1996, август 1996 года; разделы 3.7–3.8, стр. 3–4. Сохранены запреты in no case shall и разрешённое исключение data present; data same. Полная политика аутентификации DNS этим RFC не задаётся.

4. 04

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

   Граница применимости: RFC 1996, август 1996 года; раздел 3.10, стр. 4. В источнике should ignore. Проверка относится к известным источникам конкретной зоны; одного знакомого имени зоны недостаточно.

5. 05

   В этой версии NOTIFY определено уведомление об изменении SOA. Получателю рекомендуется запросить SOA у известного источника, приславшего уведомление, и проверить увеличение SERIAL; при увеличении следует начать AXFR или IXFR. Другой известный источник может ещё не успеть обновить копию.

   Граница применимости: RFC 1996, август 1996 года; раздел 3.11, стр. 4. Сохранены рекомендации should и выбор именно отправившего известного источника. Answer самого NOTIFY не заменяет отдельный запрос SOA.

6. 06

   Ответ NOTIFY подтверждает получение уведомления и позволяет отправителю убрать событие для этого получателя из очереди повторов. Для UDP отправитель сопоставляет ответ по query ID, QNAME, IP-адресу и UDP-порту источника. Такое подтверждение не означает завершение передачи зоны.

   Граница применимости: RFC 1996, август 1996 года; разделы 3.3, 3.6 и 4.8, стр. 3 и 6. Завершается notification process для данного события и сервера. Подтверждение не доказывает изменение SERIAL у получателя.

7. 07

   Промежуточный сервер должен отправлять NOTIFY дальше только после обновления своей SOA или установления, что обновление не нужно. Получателю рекомендуется отложить обработку повторного NOTIFY с теми же QNAME, QCLASS и QTYPE до завершения начатой обработки.

   Граница применимости: RFC 1996, август 1996 года; разделы 4.2 и 4.4, стр. 5. В источнике requiring и should defer. Отложить дубликат не означает навсегда запретить уведомления об этой зоне.

8. 08

   Источник зоны может задержать отправку NOTIFY, чтобы разнести начало передач во времени, но задержка не должна превышать SOA REFRESH. Случайные 30–60 секунд приведены как подходящий пример для общей локальной сети и зон умеренного размера.

   Граница применимости: RFC 1996, август 1996 года; раздел 4.3, стр. 5. Верхняя граница REFRESH обязательна по shall not; 30–60 секунд — условный пример, а не универсальная настройка.

1. Укажите источник уведомления и сервер, который хранит копию конкретной зоны.
2. После подтверждения NOTIFY отдельно проверьте SERIAL и завершение нужной передачи зоны.
3. Проверьте Notify Set, скрытые серверы и отсутствие циклов передачи зоны.
4. Сверьте адрес отправителя со списком известных источников этой зоны.
5. Не переносите данные из Answer уведомления в локальную зону.
6. Запрашивайте SOA у известного источника, приславшего уведомление.
7. Проверьте отложенную обработку дубликатов и распространение после обновления.
8. Ограничьте задержку отправки значением SOA REFRESH; пример 30–60 секунд оцените по условиям.

• Первичная спецификация

  A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

  Internet Engineering Task Force · RFC 1996, August 1996

  Полный RFC 1996 (август 1996, 7 страниц) прочитан локально 2026-09-09. Сверены Notify Set, известный источник, проверка SOA, границы подсказок и подтверждений, распространение NOTIFY. Прежняя дата получения сохранена. Последующие документы и текущие реализации не проверялись.

  Открыть первоисточник ↗