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

Manage idleness and recover from closure

05

An idle session has no work left for that endpoint. Partial bytes and interrupted replies need careful handling so idle connections do not consume resources forever.

DIAGRAMRead RFC section 6.2.3 ↗
RFC 7766 · § 6.2.3EXAMPLE
4 / 4
Manage idleness and recover from closureFirst, C1 has A outstanding so the client is not idle. After answering A and no other pending work, both endpoint views are idle. A separate partial-input case has 10 of 32 bytes and does not reset the idle timer for each segment. A separate interruption closes C1 with B unanswered: no old response is sent, and the client retries B on new C2. No retry algorithm, fixed timer, DSO or Fast Open handshake is simulated.Ordinary DNS session · separate casesSeparate case: C1 closed · B unansweredOld server MUST NOT send on closed C1ClientServerC2 · retry unanswered BClient SHOULD retry unanswered queriesTiming and retry algorithm: unspecified
04
Recover unanswered work on a new connection.

Separate interruption example: C1 closes while B is outstanding. The old server stops trying to send its pending response on C1. The client retries B on new C2; retry timing and limits are local policy.

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

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

Close responsibly; retry unanswered work.

  • Clients MUST take care to minimize idle time and SHOULD close an idle TCP session unless another signalling mechanism established a timeout. Servers are recommended to use default idle periods on the order of seconds, with no particular value specified; zero timeouts MAY be used under heavy load or attack.
  • Servers SHOULD reset the idle timeout on receipt of a full DNS message, rather than any partial segment. A client is idle only when it has neither pending questions to send nor outstanding responses; a server is idle when it has answered all received queries.
  • Clients SHOULD retry unanswered queries after connection closure; RFC 7766 specifies no retry algorithm. A server that discovers the session closed or interrupted MUST NOT attempt to send pending responses on it, though it MAY cache them.
DETAILS

RFC 8490 §5.2 replaces these inactivity and termination rules once a DNS Stateful Operations (DSO) session is established; DSO is not used in these ordinary DNS examples. RFC 7766 §9 discusses TCP Fast Open non-normatively: it can reduce reopening cost, but protected DNS must not accidentally send its queries in cleartext. This is not a retry-count, universal idle-timer, TLS or DSO implementation.

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 ↗