DNS и разрешение имён · проверено по источникам

AXFR: приёмка копии и право на передачу

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

Также ищут: AXFR zone integrity · AXFR authorization

Практический смысл

Почему это важно

Практическое пояснение: новая SOA или большой объём принятых данных не разрешают обслуживать неполную зону. Политика допуска клиента также не заменяет проверку того, что полученная копия пригодна для включения.

Доказательная часть

Что подтверждено

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

    Граница применимости: RFC 5936, июнь 2010 года; §6, стр. 23. Требуется эквивалентное внешнее поведение, а не конкретная схема файлов, таблиц или транзакций. Полнота передачи не заменяет проверок содержимого.

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

    Граница применимости: RFC 5936, июнь 2010 года; §6, стр. 23. Удаляется отклонённый новый набор. RFC 5936 не превращает это правило в разрешение бессрочно обслуживать старую копию вопреки другим условиям её действительности.

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

    Граница применимости: RFC 5936, июнь 2010 года; §6, стр. 24. SHOULD для запоминания отделено от MAY для повтора. Повторная попытка не является автоматической приёмкой прежнего отклонённого набора.

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

    Граница применимости: RFC 5936, июнь 2010 года; §5, стр. 23. Перечислены рекомендации RFC 5936 2010 года. Современный выбор алгоритмов и настройка конкретного сервера по этому чтению не подтверждаются.

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

    Граница применимости: RFC 5936, июнь 2010 года; §5, стр. 23. SHOULD для возможности настройки и SHOULD NOT для исходного состояния не противоречат друг другу. Операторский выбор не объявляется заводским допуском.

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

    Граница применимости: RFC 5936, июнь 2010 года; §6, стр. 24. Рекомендация и два назначения приведены в RFC 5936. Алгоритмы, жизненный цикл ключей и шифрование канала данным утверждением не задаются.

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

    Граница применимости: RFC 5936, июнь 2010 года; §2.2.5, стр. 15. Обязанность условна: метод поддерживается обеими сторонами. Точное расположение подписей в последовательности определяется самим методом; обязательная подпись каждого сообщения здесь не выдумывается.

Перед спецификацией

Что проверить

  1. Укажите, какие проверки выполняются до включения новой копии.
  2. Проверьте, что читатели не видят частично включённую зону.
  3. После ошибки проверьте удаление нового набора и сохранение прежней допустимой копии.
  4. Различайте запомненный отклонённый SERIAL и запрет всех дальнейших попыток этой версии.
  5. Сверьте список допущенных клиентов отдельно от наличия функции AXFR.
  6. Проверьте исходную политику доступа и сознательные изменения оператора.
  7. Проверьте целостность ответа по выбранному методу защиты, отдельно от права на передачу.
Открытые основания

Первоисточники

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

    DNS Zone Transfer Protocol (AXFR)

    Internet Engineering Task Force · RFC 5936, June 2010

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

    Открыть первоисточник
Сообщить об ошибке

Опишите проблему — постараемся исправить как можно скорее.

Спасибо!

Получили ваше сообщение.
Подтвердите действие