Summary

  • RFC 8490 distinguishes a connected DNS transport from an established DNS Stateful Operations session. State begins only after an explicit successful exchange, not because a socket happens to exist.
  • Its message identifiers, one-primary-TLV rule, separate inactivity and keepalive timers, Retry Delay and termination semantics make long-lived state bounded and attributable without pretending to prove universal deployment.
  • The durable control question is not whether a connection is alive, but who created each operation, what keeps it valid, which limit ends it and what evidence governs reconnection.

The socket with no mandate

Traditional DNS makes a compact promise. A client asks a question; a server returns a response. TCP can carry many such exchanges over one connection, but the open connection does not by itself say that either endpoint may establish a subscription, push a later change or retain application state after a reply. Transport continuity is not application authority.

RFC 8490, published in March 2019 and co-authored by Ray Bellis with Stuart Cheshire, John Dickinson, Sara Dickinson, Ted Lemon and Tom Pusateri, addresses that gap. It defines DNS Stateful Operations, or DSO, under OPCODE 6. The document updates the original DNS specification and the later DNS-over-TCP requirements. Its consequential move is conceptual: it names a state in which both endpoints know that persistent DNS operations exist and know the rules that govern them.

A client first has a connection. It may send ordinary DNS requests. That connection becomes a DSO session only after a successful DSO request and matching response, apart from narrowly specified early-data cases. If an old server does not understand the opcode, the client cannot safely act as though state was established. Silence eventually requires an abort and a fresh connection in a known state. A live socket is therefore evidence of reachability, not consent to a new protocol.

One operation owns the message

DSO reuses the twelve-byte DNS header but not the ordinary question and answer sections. Its work is carried in Type-Length-Value structures. Every message has one Primary TLV. That primary operation determines whether the message is a request requiring acknowledgement or a unidirectional message that must not receive a response.

The MESSAGE ID makes the difference visible. A DSO request uses a nonzero identifier and must elicit a response with the matching value. A unidirectional message uses zero. This prevents an implementation from treating every signal as a transaction or every transaction as a fire-and-forget notice. It also permits requests to be pipelined and replies to arrive out of order while requiring the receiver to act on messages in received order.

The one-primary-operation rule is a small constitutional choice. EDNS can combine several options in one OPT record, leaving each option specification to explain whether and how processing is acknowledged. DSO instead gives each operation its own message and one result code. Additional TLVs may qualify the primary operation only where its definition permits them. An unknown primary TLV receives the dedicated DSOTYPENI response; an unknown additional TLV is ignored. Extensibility no longer requires pretending that unrecognized meaning was accepted.

Two clocks, not one

Long-lived state creates a resource problem. A quiet connection might be abandoned, or it might carry a valid subscription waiting for change. RFC 8490 therefore separates the inactivity timeout from the keepalive interval.

The inactivity timer is about useful operations. It does not run while an ordinary request is awaiting its response, and a long-lived operation remains active until cancelled even if no messages flow. The keepalive timer is about continued reachability. Keepalive traffic may preserve NAT and firewall state and confirm that peers can still communicate, but it is not ordinary DNS activity. A pulse proves that the path is alive; it does not prove that the retained state is still valuable.

That distinction prevents two opposite errors. If every quiet interval were treated as abandonment, useful subscriptions would constantly collapse. If any keepalive packet renewed application authority forever, stale state could become immortal. Operators need both clocks, plus visibility into the outstanding operation that justifies keeping state.

Ending state without a stampede

Persistent sessions also need an exit. DSO defines Retry Delay so a server can terminate a session and tell a client how long to wait before reconnecting. The reason code can distinguish a routine restart, malformed input, resource exhaustion or reconfiguration. These signals let clients avoid turning a controlled shutdown into a reconnection storm.

The signal remains bounded evidence. SERVFAIL may indicate load shedding, but it does not reveal the private cause of exhaustion. REFUSED may indicate that a prior operation can no longer be served, but it is not proof of misconduct or permanent withdrawal. A retry delay is a coordination instruction, not ownership of the client.

The transport boundary is equally deliberate. DSO requires reliable, ordered session semantics and is defined for DNS over TCP and DNS over TLS. It does not run over ordinary DNS/UDP, which lacks those session properties. It also does not run over DNS over HTTPS, because HTTP has its own session machinery. Encryption may protect the channel, but DSO does not make every peer trustworthy or every retained operation appropriate.

The state that later work could use

RFC 8765 uses DSO for DNS Push Notifications. A subscriber can ask for changes and receive later updates without polling the entire namespace repeatedly. That concrete use shows why the framework mattered: the innovation is not merely a longer connection, but a shared lifecycle on which another protocol can safely place continuing work.

The IANA DNS Parameters registry records DSO type codes and the DSO error code. Registration makes the extension space public and collision-resistant. It does not measure how many implementations support it, how well timers are configured or whether a given deployment shares connections correctly.

Ray Bellis's contribution is best read through this discipline of boundaries. The RFC does not claim a permanent right to state. It makes establishment, use, silence, reachability, overload, termination and retry different events. That is what lets later DNS features depend on persistence without allowing persistence itself to become invisible authority.

Sources