Почему это важно
Практическое пояснение: если отправитель сам исправит NS или glue по данным дочерней зоны, одна версия начнёт означать разные наборы записей. При приёмке важно проверить и состав, и принадлежность данных конкретной зоне.
Что подтверждено
Цель AXFR — восстановить содержимое зоны для заданного SERIAL так, как оно доступно при обслуживании DNS-запросов. Внутреннее представление в файле зоны или базе данных отправителя воспроизводить не требуется.
Граница применимости: RFC 5936, июнь 2010 года; §3, стр. 15. Внешнее поведение зоны отделено от формата хранилища. AXFR не заявляется резервной копией всей конфигурации сервера.
Ответ AXFR должен включать записи зоны для заданного SERIAL. Зона, весь состав которой для одной версии невозможно практически перечислить, непригодна для получения через AXFR.
Граница применимости: RFC 5936, июнь 2010 года; §3.1, стр. 15, 16. Пример документа — постоянно меняющиеся вычисляемые ответы. Само использование базы данных не объявляется запретом на AXFR.
При передаче родительской зоны AXFR должен включать NS делегирования, зарегистрированные именно в этой зоне. Их нельзя заменить NS вершины дочерней зоны только потому, что отправитель также обслуживает дочернюю зону и видит расхождение.
Граница применимости: RFC 5936, июнь 2010 года; §3.2, стр. 17, 18. Расхождение остаётся эксплуатационной ошибкой, которую нужно видеть и исправлять отдельно. Передача не должна скрывать её подменой данных.
AXFR должен включать относящиеся к зоне связующие адресные записи glue в том виде, в котором они зарегистрированы для передаваемой версии. Несовпадение с авторитетным адресом сервера не разрешает исправить glue во время передачи.
Граница применимости: RFC 5936, июнь 2010 года; §3.3, стр. 18, 19. Правило охватывает адресные семейства glue. Принадлежность записи зоне сохраняется; речь не о включении любого известного отправителю адреса.
В описанной RFC 5936 схеме DS делегирования относится к родительской зоне, а DNSKEY на вершине подписанной дочерней зоны — к дочерней. RRSIG и NSEC либо NSEC3 у границы включаются в AXFR той зоны, которой принадлежит соответствующая запись.
Граница применимости: RFC 5936, июнь 2010 года; §3.2, стр. 16, 17. Это приведённое в RFC 5936 пояснение состава зон, а не полный алгоритм DNSSEC. Указанные им внешние спецификации здесь самостоятельно не пересматриваются.
Добавление делегирования или DNAME может закрыть от обычного поиска подчинённые имена, ещё остающиеся в зоне. Такие закрытые имена должны входить в AXFR, а клиент должен уметь распознавать и обрабатывать их.
Граница применимости: RFC 5936, июнь 2010 года; §3.5, стр. 19, 20. Включение в передачу не открывает имя для обычного ответа DNS. В документе это помогает восстановлению после отмены ошибочного изменения.
При сжатии имён в AXFR рекомендуется сохранять регистр меток содержимого зоны. Для этой задачи буквы a и A не считаются взаимозаменяемыми, хотя при обычном сопоставлении DNS-имени регистр не различается.
Граница применимости: RFC 5936, июнь 2010 года; §3.4, стр. 19. Сохранено SHOULD, а не MUST. Полные правила сжатия RDATA из отдельного RFC 3597 этим утверждением не пересказываются.
Что проверить
- Свяжите выгружаемый набор с именем зоны и SERIAL.
- Убедитесь, что записи этой версии можно перечислить целиком.
- Сверьте NS делегирования с данными родительской зоны, а не с автоматически выбранной дочерней копией.
- Сверьте glue передаваемой версии отдельно от авторитетных адресных ответов.
- Укажите принадлежность записей DNSSEC стороне делегирования.
- Проверьте сохранение имён, закрытых делегированием или DNAME.
- Проверьте регистр меток отдельно от обычного сопоставления имени.
Первоисточники
DNS Zone Transfer Protocol (AXFR)
Internet Engineering Task Force · RFC 5936, June 2010
Полный RFC 5936 (июнь 2010, 29 страниц) прочитан локально 2026-09-09. Сверены сообщения AXFR, состав зоны, общее TCP-соединение, приёмка копии и допуск клиентов. Прежняя дата получения сохранена. Последующие RFC, errata и текущие реализации не проверялись.
Открыть первоисточник