AXFR: передать зону и принять целую копию

Запрос AXFR содержит один вопрос: имя запрашиваемой зоны, тип AXFR с кодом 252 и класс зоны. Секции Answer и Authority в запросе должны быть пустыми.

Двухоктетное поле длины DNS по TCP ограничивает одно DNS-сообщение 65 535 октетами. EDNS(0) не увеличивает этот предел; он не является пределом размера всей зоны AXFR, передаваемой несколькими сообщениями.

Успешная передача содержимого зоны начинается её SOA и заканчивается той же SOA. Промежуточные сообщения не должны содержать SOA; весь ответ может состоять и из одного сообщения.

Сервер AXFR сообщает об обнаруженной ошибке одним DNS-сообщением с соответствующим кодом ответа и завершает эту передачу. Ошибка может прийти после части данных; завершающая SOA в сообщении об ошибке не требуется.

Кроме начальной и конечной SOA, записи AXFR разрешено передавать в любом порядке и группировать по сообщениям произвольно. Клиент должен принимать такой порядок, даже если записи одного RRset оказались в разных сообщениях.

Каждую запись содержимого зоны рекомендуется передавать один раз. Если клиент AXFR получил повтор такой записи, он должен его игнорировать.

В первом сообщении ответа AXFR и в сообщении об ошибке секция Question должна повторять вопрос запроса. В остальных сообщениях она может повторяться или оставаться пустой.

Цель AXFR — восстановить содержимое зоны для заданного SERIAL так, как оно доступно при обслуживании DNS-запросов. Внутреннее представление в файле зоны или базе данных отправителя воспроизводить не требуется.

Ответ AXFR должен включать записи зоны для заданного SERIAL. Зона, весь состав которой для одной версии невозможно практически перечислить, непригодна для получения через AXFR.

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

AXFR должен включать относящиеся к зоне связующие адресные записи glue в том виде, в котором они зарегистрированы для передаваемой версии. Несовпадение с авторитетным адресом сервера не разрешает исправить glue во время передачи.

В описанной RFC 5936 схеме DS делегирования относится к родительской зоне, а DNSKEY на вершине подписанной дочерней зоны — к дочерней. RRSIG и NSEC либо NSEC3 у границы включаются в AXFR той зоны, которой принадлежит соответствующая запись.

Добавление делегирования или DNAME может закрыть от обычного поиска подчинённые имена, ещё остающиеся в зоне. Такие закрытые имена должны входить в AXFR, а клиент должен уметь распознавать и обрабатывать их.

При сжатии имён в AXFR рекомендуется сохранять регистр меток содержимого зоны. Для этой задачи буквы a и A не считаются взаимозаменяемыми, хотя при обычном сопоставлении DNS-имени регистр не различается.

Сервер AXFR должен поддерживать несколько передач AXFR и другие обмены DNS по одному TCP-соединению. RFC 5936 не определяет AXFR по UDP, даже для небольшой зоны, помещающейся в увеличенный UDP-ответ.

Клиент AXFR может начать передачу по уже открытому TCP-соединению; повторное использование рекомендуется вместо открытия нового. Если дальнейшая работа по соединению некоторое время не ожидается, клиенту рекомендуется его закрыть.

Клиент выбирает Message ID, который ещё не использует с этим сервером, а сервер должен копировать его в каждое сообщение соответствующего ответа AXFR. Клиент должен уметь различать несколько незавершённых запросов; несопоставленные ответы рекомендуется отбрасывать.

Клиент может отменить получение зоны AXFR только закрытием TCP-соединения. Такое действие отменяет и всю остальную незавершённую работу на этом соединении; отдельной команды отмены одной передачи протокол не задаёт.

При удалённом закрытии TCP-соединения клиент AXFR должен отменить все незавершённые передачи и обычные DNS-обмены на нём. Сервер при удалённом закрытии отменяет свои передачи; повторную попытку инициирует клиент.

Если ответы старого сервера нельзя надёжно различить или он обрывает попытку совместной работы, клиенту не рекомендуется повторно использовать соединение с этим сервером до его обновления. При неуверенности в стабильном Message ID не рекомендуется отправлять другие запросы до конца AXFR.

После обрыва клиенту AXFR рекомендуется оценить, вызван ли он сетью или решением сервера; надёжно различить причины удаётся не всегда. Бесконечные повторы и увеличение их частоты не рекомендуются.

Клиент AXFR должен обслуживать зону только из успешно переданной копии. После завершения передачи и проверок новый набор включается атомарно; внешнее поведение должно соответствовать модели «сначала получить и проверить, затем включить целиком».

При обнаружении ошибки в полученной копии клиент AXFR должен удалить этот набор данных и продолжить обслуживание прежней версии, если обслуживал её до передачи.

Клиенту, отклонившему данные AXFR, рекомендуется запомнить SERIAL, но разрешено снова запросить ту же версию зоны. Причина отказа могла быть связана с реализацией одного источника и не повториться у другого.

Реализации DNS рекомендуется предоставлять средства ограничения AXFR определёнными клиентами, включая допуск по IP-адресам и диапазонам. Реализации общего назначения рекомендуется также поддерживать контроль доступа на основе TSIG и/или SIG(0).

Реализации DNS общего назначения рекомендуется позволять оператору открыть AXFR для всех запросов. При этом политика «открыто всем» не рекомендуется как настройка по умолчанию.

Для проверки содержимого передачи реализации DNS рекомендуется предоставлять клиентам AXFR средства TSIG и/или SIG(0). Эти же средства могут использоваться для авторизации; проверка содержимого и право запросить зону остаются разными назначениями.

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