Visual RFC.
ALL RFCs / RFC 7766
Read the RFC ↗
RFC 7766 / DNS OVER TCP

Reuse connections without exhausting the server

04

One persistent connection can carry many ordinary questions. Connection limits also need to allow for multiple real clients sharing one public address.

DIAGRAMRead RFC section 6.2.2 ↗
RFC 7766 · § 6.2.2EXAMPLE
4 / 4
Reuse connections without exhausting the serverPersistent C1 carries multiple regular queries. Separate regular-query and zone-transfer connections illustrate the per-transport recommendation updated by RFC 9103, with busy-zone exceptions and mixed-traffic server support stated in prose. Three clients behind one NAT address have distinct connections; a single-client connection count must not be applied as hard one-per-address rule. A separate local capacity gate stops a new connection before allocation, and plain TCP supplies no encryption.Reuse and resource limitsLocal capacity reached (chosen policy)No RFC numeric default is impliedConnection allocation gatenew connection stops hereLimits protect resources, not DNS authenticityPlain TCP does not encrypt DNS messages
04
Bound resources without claiming encryption.

A chosen local connection limit stops another new connection before allocation. Its number is an example, not an RFC default; accepted plain TCP traffic remains readable without another protection layer.

Source for this drawing: RFC 7766 · Read RFC section 6.2.2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 1035 DNS wire RFC 9293 TCP

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Reuse capacity; make limits fit the real clients.

  • Clients and servers SHOULD support connection reuse. Clients MUST take care to minimize concurrent TCP connections to each server.
  • RFC 9103 §6.4 updates the recommendation: for each protocol over TCP, a client/server interaction SHOULD have no more than one connection for ordinary queries and one for zone transfers, with operational exceptions for busy zones. Servers still handle mixed query and transfer traffic.
  • Servers MAY limit connections per client address or subnet. Such limits SHOULD be much looser than the client guidelines: one address may represent multiple clients behind network address translation (NAT).
DETAILS

Section 10 advises configurable totals, per-source limits, idle timeouts, transaction counts and connection duration; it specifies no numeric defaults. Limits manage resources, not DNS data authenticity. This chapter illustrates ordinary queries and explains the updated transfer boundary without pretending to implement zone transfer or DNS over TLS. Plain TCP does not encrypt DNS; TLS is a separate protocol layer.

Read the RFC section ↗

All chapters in RFC 7766

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗