Summary

  • DNS over TCP is a standard service path, not merely a zone-transfer exception.
  • EDNS enlarges the usable UDP envelope but cannot guarantee delivery across every path.
  • Readiness evidence must follow a query through truncation, TCP establishment, response completion and safe reuse.

The revealing incident begins with a green dashboard. UDP/53 answers arrive quickly and authoritative data is current. A larger answer returns with TC set. The resolver opens TCP, but the serving site has a shallow accept queue, an unsuitable firewall timeout or workers that serialize behind slow peers. The DNS data is correct. Its delivery path is not ready.

RFC 1035 defined both UDP and TCP service on port 53. It defined TCP framing with a two-octet message length and warned servers not to block other work while waiting for TCP data. The original UDP ceiling has since been extended by EDNS, but the architectural point remains: truncation changes the transport work required to finish the same question.

RFC 6891 lets a requestor advertise the largest UDP payload it can reassemble and deliver in DNS context. That field is endpoint evidence, not a promise about every intervening path. Avoiding TC in a laboratory therefore does not retire TCP from the production contract.

RFC 7766 makes TCP support mandatory for general-purpose DNS implementations and treats reuse as a way to avoid paying setup cost for every query. Reuse changes the capacity question: operators must observe concurrent completion, head-of-line effects and closing policy, not merely whether port 53 accepted one connection.

RFC 9210 sharpens the operational boundary. TCP is not proven by a socket that opened once. It is proven by bounded lifecycle behavior under the query mix the service actually carries.