AXFR: сообщения и границы полной передачи

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

1. 01

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

   Граница применимости: RFC 5936, июнь 2010 года; §§2.1.1–2.1.4, стр. 9, 10. Условия относятся к запросу AXFR; правила обычного запроса или IXFR сюда не переносятся.

2. 02

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

   Граница применимости: RFC 5936, июнь 2010 года; §2.2, стр. 11. Начальная и конечная SOA должны совпадать как ресурсные записи. Сами границы не заменяют проверку полноты и корректности полученной зоны.

3. 03

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

   Граница применимости: RFC 5936, июнь 2010 года; §2.2, стр. 11. RRset — записи с общими именем владельца, классом и типом. Обязательный порядок задаётся только для граничных SOA.

4. 04

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

   Граница применимости: RFC 5936, июнь 2010 года; §2.2, стр. 11. SHOULD для отправки отделено от MUST для клиента. Две граничные SOA выполняют собственную роль и не объявляются ошибочным дубликатом.

5. 05

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

   Граница применимости: RFC 5936, июнь 2010 года; §§2.2 и 2.2.2, стр. 11, 12, 14. Пустая Question допустима в последующих сообщениях без ошибки; она не делает обязательную секцию первого ответа необязательной.

6. 06

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

   Граница применимости: RFC 5936, июнь 2010 года; §2.2, стр. 12. Полученные до ошибки данные не превращают оборванную передачу в успешную. Завершение передачи не тождественно закрытию общего TCP-соединения.

7. 07

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

   Граница применимости: RFC 5936, июнь 2010 года; §2, стр. 8. Число относится к DNS-сообщению без двухоктетного префикса; ограничения буфера и общей зоны конкретной реализации проверяются отдельно.

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

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