Кратко

  • TCP — штатный путь DNS, а не исключение только для передачи зон.
  • EDNS расширяет доступный размер UDP, но не гарантирует доставку по каждому пути.
  • Готовность нужно доказывать от усечения до установки TCP, полного ответа и безопасного повторного использования соединения.

Показательный сбой начинается с зелёной панели. UDP/53 отвечает быстро, авторитетные данные актуальны. Более крупный ответ приходит с битом TC. Резолвер открывает TCP, но у узла мала очередь приёма, межсетевой экран использует неподходящий тайм-аут либо рабочие процессы задерживаются за медленным клиентом. Данные DNS верны; путь их доставки не готов.

RFC 1035 определила DNS по UDP и TCP на порту 53 и двухоктетный префикс длины сообщения для TCP. Она рекомендует несколько соединений и запрещает ожиданию TCP блокировать другую работу. EDNS позднее расширил исходный предел UDP, но усечение по-прежнему меняет транспортную работу, необходимую для завершения того же запроса.

RFC 6891 позволяет запрашивающей стороне объявить максимальный размер полезной нагрузки UDP, который она способна повторно собрать и передать DNS. Это свидетельство возможностей конечной стороны, а не обещание для каждого промежуточного участка. Отсутствие TC в лаборатории не исключает TCP из производственного контракта.

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

RFC 9210 обновляет эту эксплуатационную границу. Однократное открытие сокета не доказывает управляемый жизненный цикл при реальной смеси запросов. Полезный тест прослеживает весь переход и фиксирует причину сохранения, закрытия или сброса соединения.