Почему это важно
Практическое пояснение: начальная SOA с новой версией ещё не показывает, что клиент получил и применил всю передачу. В журнале полезно раздельно фиксировать заявленный SERIAL и завершение обновления.
Что подтверждено
Клиент IXFR — вторичный сервер, который запрашивает передачу; сервером IXFR может быть первичный или вторичный сервер. Запрос имеет тип IXFR и содержит SOA версии клиента в секции Authority.
Граница применимости: RFC 1995, август 1996 года; разделы 1 и 3, стр. 1–2. Роли определяются направлением конкретного обмена. SOA в запросе сообщает версию клиента, а не требуемый номер будущей версии.
Если инкрементальная передача недоступна, на запрос IXFR возвращается полная зона. Сервер также может выбрать полный ответ. Первая и последняя ресурсные записи полного ответа — SOA зоны, а тип запроса остаётся IXFR.
Граница применимости: RFC 1995, август 1996 года; разделы 2 и 4, стр. 2–3. Название запроса не гарантирует передачу только изменений. Полная современная спецификация AXFR этим описанием не заменяется.
В инкрементальном ответе список последовательностей изменений окружён SOA текущей версии сервера. Ответ начинается с двух SOA: сначала текущей версии сервера, затем заменяемой версии клиента.
Граница применимости: RFC 1995, август 1996 года; раздел 4, стр. 3. Начало ответа помогает распознать формат, но не доказывает успешную обработку всех разностей или завершение передачи.
Одна последовательность разностей IXFR содержит удаляемые, затем добавляемые записи. Список удалений начинается со старой SOA, список добавлений — с новой SOA. Изменение записи передаётся удалением прежней и добавлением изменённой записи; остальные записи того же типа могут не передаваться.
Граница применимости: RFC 1995, август 1996 года; раздел 4, стр. 3. Отсутствие неизменённой записи в разности не означает удаление этой записи из рабочей копии зоны.
Последовательности разностей IXFR идут от самых старых изменений к самым новым. Они описывают историю от версии, известной клиенту, до текущей версии сервера.
Граница применимости: RFC 1995, август 1996 года; раздел 4, стр. 3. Порядок применения определяется историей изменений. Это не команда сортировать SERIAL как обычные целые числа.
Клиенту IXFR следует заменять старую версию зоны новой только после успешной обработки всех разностей.
Граница применимости: RFC 1995, август 1996 года; раздел 4, стр. 3. В источнике should only replace. Рекомендация относится к полной обработке, а не к получению одной начальной SOA.
Одиночная SOA в ответе IXFR имеет разные причины: версия клиента совпадает с серверной или новее неё, либо полный ответ не помещается в UDP-пакет. Во втором случае SOA текущей версии сервера указывает клиенту на необходимость запроса IXFR по TCP.
Граница применимости: RFC 1995, август 1996 года; раздел 2, стр. 2; пример раздела 7, стр. 7. Сам факт получения одной SOA не доказывает совпадение копий. Нужны версия клиента и транспорт данного обмена; правила выбора транспорта описаны в версии RFC 1995.
Что проверить
- Укажите сервер, который запрашивает копию, и сервер, который отвечает на IXFR.
- Проверьте, что рабочая версия меняется после обработки всей последовательности разностей.
- Проверьте SOA версии клиента в секции Authority запроса.
- Различайте полный ответ и инкрементальную последовательность по содержимому.
- Обрабатывайте удаления и добавления в заданном порядке.
- Не удаляйте неизменённые записи из-за отсутствия в переданной разности.
- Для одиночной SOA сопоставьте версии и проверьте необходимость продолжения по TCP.
Первоисточники
Incremental Zone Transfer in DNS
Internet Engineering Task Force · RFC 1995, August 1996
Полный RFC 1995 (август 1996, 8 страниц) прочитан локально 2026-09-09. Сверены запрос и ответы IXFR, применение разностей, сохранение зоны, удаление и свёртка истории. Прежняя дата получения сохранена. Последующие документы и текущие реализации не проверялись.
Открыть первоисточник