DNS по TCP: выбор транспорта и повторное использование соединения
Определение
DNS по TCP — это передача обычных DNS-запросов и ответов по установленному TCP-соединению вместо отдельных UDP-пакетов. Обратиться по TCP можно сразу, не пробуя сначала UDP, а одно открытое соединение используют для нескольких запросов.
Также ищут: DNS TCP connection reuse · Постоянное соединение DNS
Зачем это знать
Практическое пояснение: успешный короткий ответ по UDP не проверяет работу DNS по TCP. При разборе задержки полезно различать установление нового соединения и обмен по уже открытому.
Карта понятия
Что подтверждено
Реализации DNS общего назначения должны поддерживать UDP и TCP. RFC 7766 отдельно требует поддержку TCP от авторитетных серверов, рекурсивных серверов и пересылающих запросы серверов, а также от локальных DNS-клиентов.
Граница применимости: RFC 7766, март 2016 года; раздел 5, стр. 5–6. Требования MUST относятся к реализациям. Это не результат проверки конкретного сервера или сетевого пути.
Локальные DNS-клиенты и рекурсивные резолверы могут выбирать UDP или TCP по условиям эксплуатации. Разрешено отправить запрос по TCP до любых запросов по UDP; обязательной предварительной попытки по UDP нет.
Граница применимости: RFC 7766, март 2016 года; раздел 5, стр. 6. Разрешение MAY не превращается в требование всегда выбирать TCP. Правило описано для указанных ролей.
Рекурсивные и авторитетные DNS-серверы должны отвечать тем же транспортом, которым получен запрос. Для TCP ответ должен идти по тому же соединению.
Граница применимости: RFC 7766, март 2016 года; раздел 5, стр. 6. Оба условия имеют MUST. Совпадение IP-адреса сервера не заменяет совпадение TCP-соединения.
Постоянное TCP-соединение сервер не закрывает сразу после отправки первого ответа, а клиент — сразу после получения первого ответа. Повторное использование означает передачу нескольких DNS-запросов и ответов по одному соединению.
Граница применимости: RFC 7766, март 2016 года; раздел 3, стр. 4. Это определения persistent connection и connection reuse. Постоянное не означает бессрочное или неразрываемое.
Клиентам и серверам рекомендуется поддерживать повторное использование TCP-соединения для нескольких DNS-запросов и ответов. Резолверу, у которого уже открыто соединение с нужным сервером, рекомендуется использовать это соединение.
Граница применимости: RFC 7766, март 2016 года; разделы 5 и 6.2.1, стр. 6 и 8. В обоих случаях используется SHOULD. Срок жизни соединения этим не гарантируется.
Дополнительная задержка установления TCP-соединения обычно составляет один RTT — время обмена туда и обратно. Повторное использование позволяет распределить эти затраты между несколькими DNS-запросами.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.1, стр. 8. Описана обычная стоимость установления и её распределение. Это не измеренная задержка полного разрешения имени и не обещание скорости конкретной реализации.
Раздел 9 о TCP Fast Open имеет ненормативный статус. Передача данных при установлении соединения может сократить задержку обмена максимум на один RTT по сравнению с обычным TCP.
Граница применимости: RFC 7766, март 2016 года; раздел 9, стр. 11. До одного RTT не означает гарантированную экономию одного RTT. Полная спецификация TFO и защита данных DNS-over-TLS здесь не разбираются.
Что проверить
- Укажите роли клиента и сервера и проверьте поддержку обоих транспортов.
- Отдельно проверьте обмен по новому и уже открытому TCP-соединению.
- Проследите, по какому соединению сервер возвращает ответ.
- Различайте разрешение MAY, рекомендацию SHOULD и требование MUST.
- Измеряйте полную операцию; не выдавайте стоимость установления за всю задержку DNS.
Первоисточники
- DNS Transport over TCP - Implementation Requirements
Полный текст RFC 7766 (март 2016) прочитан локально 09.09.2026 при подготовке кластера «DNS по TCP»; сверены заголовок, редакция и нормы о поддержке TCP, усечении и соединениях. retrieved_on — дата постановки в очередь.