Практикум по RFC 5936

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

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

Практика → проверка решения150 минут10 модулей20 вопросов
После курса

Что вы сможете сделать

  1. Проверять запрос, границы SOA, группировку и завершение ответа AXFR.
  2. Определять состав передаваемой зоны при делегировании и закрытых именах.
  3. Учитывать соседние обмены, Message ID и последствия закрытия TCP-соединения.
  4. Разделять полноту копии, её атомарное включение и право клиента на передачу.
Модуль 1 из 10

Запрос и размер одного сообщения

Практикум опирается на полный RFC 5936 от июня 2010 года. Клиент здесь запрашивает копию зоны, сервер отвечает. Современные расширения, алгоритмы защиты и настройки конкретного продукта этим чтением не подтверждаются.

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

    Проверить тезис: AXFR: сообщения и границы полной передачи 01

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

    Проверить тезис: AXFR: сообщения и границы полной передачи 07

Модуль 2 из 10

SOA и ошибка после части данных

Завершение отдельного сообщения и завершение всей передачи — разные события. Для успешной границы сравнивается вся ресурсная запись SOA, а для ошибки действует отдельное правило.

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

    Проверить тезис: AXFR: сообщения и границы полной передачи 02

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

    Проверить тезис: AXFR: сообщения и границы полной передачи 06

Модуль 3 из 10

Группировка, повторы и Question

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

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

    Проверить тезис: AXFR: сообщения и границы полной передачи 03

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

    Проверить тезис: AXFR: сообщения и границы полной передачи 04

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

    Проверить тезис: AXFR: сообщения и границы полной передачи 05

Модуль 4 из 10

Набор зоны и возможность перечисления

Цель передачи — обслуживаемое содержимое конкретной версии. Способ хранения и возможность перечислить записи проверяются отдельно: база данных сама по себе не препятствие.

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

    Проверить тезис: AXFR: состав зоны, делегирование и скрытые записи 01

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

    Проверить тезис: AXFR: состав зоны, делегирование и скрытые записи 02

Модуль 5 из 10

Родительские NS, glue и сторона DNSSEC

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

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

    Проверить тезис: AXFR: состав зоны, делегирование и скрытые записи 03

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

    Проверить тезис: AXFR: состав зоны, делегирование и скрытые записи 04

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

    Проверить тезис: AXFR: состав зоны, делегирование и скрытые записи 05

Модуль 6 из 10

Закрытые имена и регистр при сжатии

Состав зоны шире текущего результата обычного поиска. Регистр при сжатии также имеет отдельное правило; нормативную рекомендацию нельзя превращать в безусловный запрет.

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

    Проверить тезис: AXFR: состав зоны, делегирование и скрытые записи 06

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

    Проверить тезис: AXFR: состав зоны, делегирование и скрытые записи 07

Модуль 7 из 10

Общее соединение и Message ID

Одно соединение может обслуживать несколько передач и обычные запросы. Идентификатор связывает ответ с запросом; он не доказывает подлинность содержимого.

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

    Проверить тезис: AXFR: общее TCP-соединение и прерывание передачи 01

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

    Проверить тезис: AXFR: общее TCP-соединение и прерывание передачи 02

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

    Проверить тезис: AXFR: общее TCP-соединение и прерывание передачи 03

Модуль 8 из 10

Отмена, старый сервер и повторы

Отмена относится к общей транспортной связи. Совместимость с конкретным старым сервером не отменяет требований к исправному серверу; для повторов документ задаёт границы поведения, а не готовые интервалы.

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

    Проверить тезис: AXFR: общее TCP-соединение и прерывание передачи 04

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

    Проверить тезис: AXFR: общее TCP-соединение и прерывание передачи 05

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

    Проверить тезис: AXFR: общее TCP-соединение и прерывание передачи 06

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

    Проверить тезис: AXFR: общее TCP-соединение и прерывание передачи 07

Модуль 9 из 10

Включение новой копии и отклонённый SERIAL

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

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

    Проверить тезис: AXFR: приёмка копии и право на передачу 01

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

    Проверить тезис: AXFR: приёмка копии и право на передачу 02

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

    Проверить тезис: AXFR: приёмка копии и право на передачу 03

Модуль 10 из 10

Допуск клиента и проверка обмена

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

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

    Проверить тезис: AXFR: приёмка копии и право на передачу 04

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

    Проверить тезис: AXFR: приёмка копии и право на передачу 05

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

    Проверить тезис: AXFR: приёмка копии и право на передачу 06

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

    Проверить тезис: AXFR: приёмка копии и право на передачу 07

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01Клиент запрашивает полную копию зоны example. класса IN. В заготовке QTYPE=AXFR, один вопрос, пустая Answer и прежняя SOA в Authority. Как исправить запрос по RFC 5936?
02Инженер разбивает большую зону AXFR на сообщения по TCP. Какова максимальная длина одного DNS-сообщения в октетах без двухоктетного префикса, в том числе при EDNS(0)?
03В начале и конце полученного AXFR совпадают имя зоны и SERIAL, но различается поле refresh в SOA. Какую проверку границ обязан выполнить клиент?
04Сервер уже отправил часть зоны AXFR и обнаружил ошибку. Как оформить завершающее сообщение с кодом ошибки по RFC 5936?
05Две A-записи одного RRset пришли в разных сообщениях AXFR, между ними переданы другие имена. Граничные SOA совпадают. Какое правило группировки должен применять клиент?
06Обычная запись содержимого повторилась в AXFR между граничными SOA. Как RFC 5936 разделяет правило отправки и обработку повтора клиентом?
07Источник хранит зону в базе данных, получатель — в текстовом файле. Что требуется восстановить получателю через AXFR для заданного SERIAL?
08Для одного SERIAL источник непрерывно создаёт новые имена, и весь состав зоны практически нельзя перечислить. Что следует из этого условия по RFC 5936?
09Один сервер обслуживает родительскую и дочернюю зоны. NS делегирования родителя расходится с NS дочерней вершины. Какой набор NS должен попасть в AXFR родительской версии?
10В передаваемой версии родителя зарегистрированы glue A и AAAA. Отдельный авторитетный ответ A уже содержит другой адрес. Какие данные передать через AXFR?
11Оператор проверяет DS делегирования и DNSKEY подписанной дочерней вершины. Какая принадлежность соответствует схеме, описанной RFC 5936?
12Прежние имена закрыты делегированием от обычного поиска, но остаются в зоне. Разработчик также выбирает правило сжатия меток. Какая пара точно сохраняет требования RFC 5936?
13Разработчик выбирает транспортный контракт RFC 5936 для маленьких зон и нескольких одновременных передач. Какой вариант соответствует документу?
14На общем TCP-соединении идут два AXFR с разными Message ID. Сервер соответствует RFC 5936. По какому правилу клиент относит каждое сообщение к ожидающему запросу?
15По общему соединению идут AXFR A, AXFR B и обычный запрос C. Клиент хочет отменить A предусмотренным в RFC 5936 способом. Каковы действие и последствия?
16Старый сервер меняет ID внутри AXFR, из-за чего ответы общего TCP-соединения нельзя надёжно сопоставить. Какой режим до обновления сервера рекомендует RFC 5936?
17После удалённого закрытия соединения незавершённые обмены отменены. Какой план повторной попытки соответствует рекомендациям RFC 5936?
18Получатель обслуживает прежнюю допустимую зону и принимает новую через AXFR. Когда новый набор можно сделать доступным обычным запросам?
19Получатель обслуживал допустимую прежнюю версию. Проверка нового набора AXFR выявила ошибку. Другие условия действительности прежней копии сохраняются. Какие действия соответствуют RFC 5936?
20Как RFC 5936 сочетает возможность оператора открыть AXFR всем и исходную настройку общего DNS-сервера?
Проверяемая база

Источники курса

Полные сведения о первоисточниках приведены один раз для всего курса. Под тезисами — ссылки на соответствующие утверждения Архивариума.

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

    DNS Zone Transfer Protocol (AXFR)

    Internet Engineering Task Force · RFC 5936, June 2010

    Полный RFC 5936 (июнь 2010, 29 страниц) прочитан локально 2026-09-09. Сверены сообщения AXFR, состав зоны, общее TCP-соединение, приёмка копии и допуск клиентов. Прежняя дата получения сохранена. Последующие RFC, errata и текущие реализации не проверялись.

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

Delect.ru — информационный справочник: сведения о ценах, наличии и брендах формируются из данных витрины для анализа и сравнения. Наличие по данным витрины лучше дополнительно уточнять у выбранного поставщика; перед закупкой обязательно ставьте резервы. Сервис не является посредником при сделке и не сторона договора; коммерческие условия согласуются напрямую с выбранным дистрибьютором. Обозначения брендов приводятся для идентификации предложений.

Подтвердите действие