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

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

1. 01

   Реализации DNS общего назначения должны поддерживать UDP и TCP. RFC 7766 отдельно требует поддержку TCP от авторитетных серверов, рекурсивных серверов и пересылающих запросы серверов, а также от локальных DNS-клиентов.

   Граница применимости: RFC 7766, март 2016 года; раздел 5, стр. 5–6. Требования MUST относятся к реализациям. Это не результат проверки конкретного сервера или сетевого пути.

2. 02

   Локальные DNS-клиенты и рекурсивные резолверы могут выбирать UDP или TCP по условиям эксплуатации. Разрешено отправить запрос по TCP до любых запросов по UDP; обязательной предварительной попытки по UDP нет.

   Граница применимости: RFC 7766, март 2016 года; раздел 5, стр. 6. Разрешение MAY не превращается в требование всегда выбирать TCP. Правило описано для указанных ролей.

3. 03

   Рекурсивный и авторитетный DNS-серверы должны отвечать тем же транспортом, которым получен запрос. Для TCP ответ должен идти по тому же соединению.

   Граница применимости: RFC 7766, март 2016 года; раздел 5, стр. 6. Оба условия имеют MUST. Совпадение IP-адреса сервера не заменяет совпадение TCP-соединения.

4. 04

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

   Граница применимости: RFC 7766, март 2016 года; раздел 3, стр. 4. Это определения persistent connection и connection reuse. Постоянное не означает бессрочное или неразрываемое.

5. 05

   Клиентам и серверам рекомендуется поддерживать повторное использование TCP-соединения для нескольких DNS-запросов и ответов. Резолверу, у которого уже открыто соединение с нужным сервером, рекомендуется использовать это соединение.

   Граница применимости: RFC 7766, март 2016 года; разделы 5 и 6.2.1, стр. 6 и 8. В обоих случаях используется SHOULD. Срок жизни соединения этим не гарантируется.

6. 06

   Дополнительная задержка установления TCP-соединения обычно составляет один RTT — время обмена туда и обратно. Повторное использование позволяет распределить эти затраты между несколькими DNS-запросами.

   Граница применимости: RFC 7766, март 2016 года; раздел 6.2.1, стр. 8. Описана обычная стоимость установления и её распределение. Это не измеренная задержка полного разрешения имени и не обещание скорости конкретной реализации.

7. 07

   Раздел 9 о TCP Fast Open имеет ненормативный статус. В нём описана возможность передавать данные при установлении соединения и экономить до одного RTT по сравнению с обычным TCP.

   Граница применимости: RFC 7766, март 2016 года; раздел 9, стр. 11. До одного RTT не означает гарантированную экономию одного RTT. Полная спецификация TFO и защита данных DNS-over-TLS здесь не разбираются.

1. Укажите роли клиента и сервера и проверьте поддержку обоих транспортов.
2. Отдельно проверьте обмен по новому и уже открытому TCP-соединению.
3. Проследите, по какому соединению сервер возвращает ответ.
4. Различайте разрешение MAY, рекомендацию SHOULD и требование MUST.
5. Измеряйте полную операцию; не выдавайте стоимость установления за всю задержку DNS.

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

  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 — дата постановки в очередь.

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