AXFR: общее TCP-соединение и прерывание передачи

Практическое пояснение: кнопка отмены одной большой выгрузки может оборвать соседние запросы. Клиенту нужен учёт операций общего соединения, а не предположение о равенстве передачи и TCP-сеанса.

1. 01

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

   Граница применимости: RFC 5936, июнь 2010 года; §§4, 4.1.2 и 4.2, стр. 20, 22. Это контракт RFC 5936 для соответствующего сервера. Возможность переноса обычного запроса по UDP не расширяет транспорт AXFR.

2. 02

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

   Граница применимости: RFC 5936, июнь 2010 года; §4.1.1, стр. 21, 22. Рекомендация зависит от ожидаемой работы. Документ не задаёт здесь универсальный таймаут или обязательное новое соединение для каждой зоны.

3. 03

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

   Граница применимости: RFC 5936, июнь 2010 года; §§2.1.1 и 2.2.1, стр. 9, 13. Сохранены область выбора ID в RFC 5936 и MUST для сервера; SHOULD относится к отбрасыванию несопоставленного ответа. Это сопоставление, не криптографическая проверка.

4. 04

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

   Граница применимости: RFC 5936, июнь 2010 года; §4.1.1, стр. 21. Речь о способах отмены в RFC 5936. Поведение интерфейса или планировщика конкретного продукта сюда не входит.

5. 05

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

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

6. 06

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

   Граница применимости: RFC 5936, июнь 2010 года; §§2.2.1 и 4.1.1, стр. 13, 22. Условия совместимости сохранены. Документ не запрещает повторное использование с исправным сервером и не предоставляет автоматического сообщения о его обновлении.

7. 07

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

   Граница применимости: RFC 5936, июнь 2010 года; §§2.3 и 4.1.1, стр. 15, 21. SHOULD и SHOULD NOT не усилены до MUST. Число попыток, интервалы и универсальный алгоритм задержки документ не устанавливает.

1. Различайте TCP-соединение и каждую передачу зоны на нём.
2. Проверьте параллельные передачи и обычный запрос по тому же соединению.
3. Сопоставляйте каждое сообщение ответа с ожидаемым Message ID.
4. Перед отменой одной передачи учтите остальные операции общего соединения.
5. Проверьте отмену всего незавершённого обмена после удалённого закрытия.
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 и текущие реализации не проверялись.

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