Visual RFC.
ALL RFCs / RFC 7828
Read the RFC ↗
RFC 7828 / SIGNAL DNS IDLE TIME

Start idle time after the work is done

03

An idle connection has no work left for that endpoint. The client honors the newest signalled timeout, rather than counting from initial connection setup.

DIAGRAMRead RFC section 3 ↗
RFC 7828 · § 3EXAMPLE
4 / 4
Start idle time after the work is doneClient-local timeline has query outstanding, so there is initially no idle countdown. With all work done at 10000 ms and 600 units, the idle deadline is 70000 ms. A separate later exchange interrupts idle time and returns 50 units; new idle start 20000 ms gives a 25000 ms deadline. Closing starts at 24000 ms, before that deadline. Client/server idle epochs can differ and the early-close margin is illustrative, not normative.Client-local clock · milliseconds (ms)No pending or outstanding workLatest signal: 50 units = 5 secondsIdle begins at: 20000 msIdle deadline: 25000 ms20000 ms25000 msclose at 24000 ms24000 < 25000 · initiate close before expiryServer may close earlier for local resource reasons
04
Initiate closure before the new limit expires.

The example client starts closing at 24000 ms, before the 25000 ms idle deadline. That one-second margin is chosen for the illustration; the RFC specifies no fixed margin or promise the server will stay open.

Source for this drawing: RFC 7828 · Read RFC section 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 7766 DNS over TCP RFC 6891 EDNS

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

The latest timeout replaces the previous one.

  • The idle timer begins when the endpoint’s idle condition is met, and should reset when that condition is lifted by sending or receiving a message on an idle connection.
  • A client receiving the option over TCP MAY keep the connection open when idle. It SHOULD honor this response’s timeout, overriding the previous value, and initiate close before expiry.
  • Servers MUST signal their currently associated timeout when including the option. Resources may change that value; neither side is forced to retain a session until the signalled limit.
DETAILS

The timeline is explicitly the client’s view: idle means no pending queries to send and no outstanding replies. Each bar uses its own scale; its numeric endpoints define that idle interval. The server is idle after answering every query it received, so its idle epoch can differ. The example uses local clock values in milliseconds and an illustrative early-close choice, not a universal safety margin. Work arriving interrupts idleness; a new idle period uses the latest timeout. RFC 7766 supplies the endpoint definitions.

Read the RFC section ↗

All chapters in RFC 7828

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 ↗