DNS по TCP: запросы без ожидания и сопоставление ответов
Определение
Запросы без ожидания (pipelining) — это режим, в котором клиент отправляет следующий DNS-запрос по тому же TCP-соединению, не дождавшись ответа на предыдущий. Ответы могут прийти не в порядке запросов, поэтому их сопоставляют по Message ID и полям вопроса.
Также ищут: DNS TCP pipelining · Сопоставление ответов DNS по TCP
Зачем это знать
Практическое пояснение: порядок данных в TCP-потоке не означает, что сервер подготовит ответы в порядке запросов. Привязка ответа к первому ожидающему запросу может смешать результаты разных обращений.
Карта понятия
Что подтверждено
Pipelining в DNS означает передачу нескольких запросов по одному TCP-соединению без ожидания ответов на уже отправленные запросы перед отправкой следующего запроса.
Граница применимости: RFC 7766, март 2016 года; раздел 3, стр. 4. Это определение способа отправки. Одно соединение с последовательным ожиданием каждого ответа ещё не доказывает pipelining.
Клиентам DNS рекомендуется отправлять запросы без ожидания ответа на предыдущий запрос. При выборе момента отправки очередного запроса рекомендуется одинаково рассматривать TCP и UDP.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.1.1, стр. 8. SHOULD и SHOULD NOT задают рекомендации; из них не выводится обязанность одновременно отправлять любой набор запросов.
DNS-сервер должен быть готов получать несколько запросов подряд без ожидания ответов. Серверу рекомендуется обрабатывать TCP-запросы параллельно и отвечать на все такие запросы, даже если запросы получены с короткими интервалами.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.1.1, стр. 8. Готовность принимать — MUST; параллельная обработка и ответы на все запросы — SHOULD. Различие модальностей сохранено.
Авторитетным серверам и рекурсивным резолверам рекомендуется поддерживать параллельную подготовку ответов и отправку ответов не в порядке отправки запросов. Локальные DNS-клиенты и рекурсивные резолверы должны обрабатывать ответы, пришедшие не в порядке отправки запросов.
Граница применимости: RFC 7766, март 2016 года; раздел 7, стр. 10. Рекомендация серверу отделена от MUST для получателя. Это относится и к TCP, и к UDP.
Клиент не должен повторно использовать Message ID запроса, на который ещё ожидается ответ, в том же TCP-соединении. Это предотвращает совпадение идентификаторов одновременно ожидаемых ответов.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.1, стр. 8. MUST NOT ограничен запросами в обработке и одним соединением; запрет не распространяется на всю историю идентификаторов клиента.
Клиент должен сопоставлять ответ с ожидаемым запросом в том же TCP-соединении по Message ID. Если ответ содержит секцию вопроса, должны совпасть также QNAME, QCLASS и QTYPE.
Граница применимости: RFC 7766, март 2016 года; раздел 7, стр. 10. Проверка трёх полей обязательна при наличии секции вопроса. Это сопоставление сообщений, а не доказательство DNSSEC или права на действие приложения.
Что проверить
- Проверьте, отправляется ли следующий запрос до получения предыдущего ответа.
- Для каждого ожидаемого ответа храните его TCP-соединение и Message ID запроса.
- Проверьте обработку ответов, пришедших в обратном порядке.
- При наличии секции вопроса сопоставьте QNAME, QCLASS и QTYPE.
- Проверяйте получение всех ответов отдельно от скорости обработки.
Первоисточники
- DNS Transport over TCP - Implementation Requirements
Полный текст RFC 7766 (март 2016) прочитан локально 09.09.2026 при подготовке кластера «DNS по TCP»; сверены заголовок, редакция и нормы о поддержке TCP, усечении и соединениях. retrieved_on — дата постановки в очередь.