DNS по TCP: запросы без ожидания и сопоставление ответов

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

1. 01

   Pipelining в DNS означает передачу нескольких запросов по одному TCP-соединению без ожидания уже запрошенных ответов перед отправкой следующего запроса.

   Граница применимости: RFC 7766, март 2016 года; раздел 3, стр. 4. Это определение способа отправки. Одно соединение с последовательным ожиданием каждого ответа ещё не доказывает pipelining.

2. 02

   Клиентам DNS рекомендуется отправлять запросы без ожидания ответа на предыдущий запрос. При выборе момента отправки очередного запроса рекомендуется одинаково рассматривать TCP и UDP.

   Граница применимости: RFC 7766, март 2016 года; раздел 6.2.1.1, стр. 8. SHOULD и SHOULD NOT задают рекомендации; из них не выводится обязанность одновременно отправлять любой набор запросов.

3. 03

   DNS-сервер должен быть готов получать несколько запросов подряд без ожидания ответов. Серверу рекомендуется обрабатывать TCP-запросы параллельно и отвечать на все такие запросы, даже если запросы получены с короткими интервалами.

   Граница применимости: RFC 7766, март 2016 года; раздел 6.2.1.1, стр. 8. Готовность принимать — MUST; параллельная обработка и ответы на все запросы — SHOULD. Различие модальностей сохранено.

4. 04

   Авторитетным серверам и рекурсивным резолверам рекомендуется поддерживать параллельную подготовку и отправку ответов вне порядка запросов. Локальные DNS-клиенты и рекурсивные резолверы должны обрабатывать ответы, пришедшие не в порядке отправки запросов.

   Граница применимости: RFC 7766, март 2016 года; раздел 7, стр. 10. Рекомендация серверу отделена от MUST для получателя. Это относится и к TCP, и к UDP.

5. 05

   Клиент не должен повторно использовать Message ID запроса, на который ещё ожидается ответ, в том же TCP-соединении. Это предотвращает совпадение идентификаторов одновременно ожидаемых ответов.

   Граница применимости: RFC 7766, март 2016 года; раздел 6.2.1, стр. 8. MUST NOT ограничен запросами в обработке и одним соединением; запрет не распространяется на всю историю идентификаторов клиента.

6. 06

   Клиент должен сопоставлять ответ с ожидаемым запросом в том же TCP-соединении по Message ID. Если ответ содержит секцию вопроса, должны совпасть также QNAME, QCLASS и QTYPE.

   Граница применимости: RFC 7766, март 2016 года; раздел 7, стр. 10. Проверка трёх полей обязательна при наличии секции вопроса. Это сопоставление сообщений, а не доказательство DNSSEC или права на действие приложения.

1. Проверьте, отправляется ли следующий запрос до получения предыдущего ответа.
2. Для каждого ожидаемого ответа сохраняйте соединение и Message ID запроса.
3. Проверьте обработку ответов, пришедших в обратном порядке.
4. При наличии секции вопроса сопоставьте QNAME, QCLASS и QTYPE.
5. Проверяйте получение всех ответов отдельно от скорости обработки.

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

  DNS Transport over TCP - Implementation Requirements

  Internet Engineering Task Force · RFC 7766, March 2016

  Полный текст RFC 7766 (март 2016) прочитан локально 09.09.2026 при подготовке кластера «DNS по TCP»; сверены заголовок, редакция и нормы о поддержке TCP, усечении и соединениях. retrieved_on — дата постановки в очередь.

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