Summary

  • The most durable item in this record is a table row: the IANA DNS Parameters registry holds OpCode value 6 as DNS Stateful Operations, referenced to RFC 8490, alongside a DSO Type Codes table with KeepAlive, RetryDelay and EncryptionPadding. A registry entry is what survives when authorship ends.
  • The two Bellis instruments are not the same kind of object. RFC 5625 is a single-author Best Current Practice whose hard requirements mostly forbid a proxy from mangling traffic it does not understand; RFC 8490 is a six-author Proposed Standard whose prohibitions constitute a shared session. Neither document compels anyone who declines to implement it, and nothing reviewed here shows that either changed a deployed network.

The register is what does the remembering

Start with the row, because it is the least sentimental part of the story. In the IANA DNS Parameters registry, the OpCodes table gives value 6 to "DNS Stateful Operations (DSO)" with a reference to RFC 8490, and the adjacent DSO Type Codes table assigns 0x0001 KeepAlive, 0x0002 RetryDelay and 0x0003 EncryptionPadding (IANA DNS Parameters registry).

A registry assignment is a public act of a particular kind. It does not depend on the author's continued participation, it does not expire with the author's employment, and it does not require anyone's consent to remain on the books. It also does not mean what people often take it to mean. The register records that an identifier exists, what it is called and where it was defined. It says nothing about which software sends it.

That distinction is the whole argument of this briefing, and the Bellis record carries it unusually cleanly, because the same engineer appears in two documents that fail differently.

One author, one advice document

RFC 5625, DNS Proxy Implementation Guidelines, was published in August 2009 as BCP 152 (RFC 5625 information page; BCP 152 subseries). The RFC Editor lists BCP 152 as a subseries containing exactly one RFC, and the author block on that RFC credits R. Bellis of Nominet UK (RFC 5625 text). Its status-of-memo is candid about what kind of claim it is making: "This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements."

That sentence is the entire enforcement mechanism. There is no conformance programme attached to a Best Current Practice, no certification body, no test suite whose failure invalidates a product. A BCP is a considered statement of what the community believes implementers should do, offered to people who are free to disagree.

The hard verbs mostly forbid meddling

Read the mandatory sentences and a pattern emerges quickly. RFC 5625 uses its strongest language to protect traffic the proxy does not understand:

  • Section 4.1: proxies MUST ignore any unknown DNS flags and proxy those packets as usual.
  • Section 4.4: if a proxy must unilaterally truncate a response, then the proxy MUST set the TC bit.
  • Section 4.5: DNS proxies MUST be capable of proxying packets containing TKEY Resource Records.

Each of those obligations is a prohibition on interference. The document does not order a gateway to implement a feature; it forbids the gateway from destroying meaning that belongs to someone else.

The positive ambition is expressed more softly. Section 3 says it is RECOMMENDED that proxies be as transparent as possible. Section 4.4.1 says that whenever a proxy receives a request over TCP, it SHOULD forward the query over TCP and SHOULD NOT attempt the same query over UDP first. Section 5.2 recommends that the default value for the option it describes be empty. Transparency, the guiding idea, is a recommendation; not breaking things is a requirement.

That ordering is not timidity. A residential gateway is a device whose firmware stops changing long before DNS does. The author cannot know what a future extension will require of it, so the only defensible rule is the narrow one: carry what you do not understand, and declare it honestly when you truncate.

Six authors, and obligations that build something

RFC 8490, DNS Stateful Operations, is a Proposed Standard published in March 2019 that updates RFC 1035 and RFC 7766 (RFC 8490 information page). It carries six authors: R. Bellis at ISC, S. Cheshire at Apple, J. Dickinson and S. Dickinson at Sinodun, T. Lemon at Nibbhaya Consulting, and T. Pusateri as an unaffiliated contributor (RFC 8490 text).

Its status-of-memo is the Standards Track formula. The document "represents the consensus of the IETF community," has "received public review" and was "approved for publication by the Internet Engineering Steering Group." Whatever authority it holds was borrowed from a process with reviewers in it, not asserted by its authors.

And its mandatory sentences do something structurally different from RFC 5625's. They do not merely stop an intermediary from interfering; they manufacture a shared object out of two endpoints:

  • Section 5.1: a server MUST NOT initiate DSO request messages or DSO unidirectional messages until a DSO Session has been mutually established.
  • Section 5.1.1: a server implementing DSO MUST NOT return DSOTYPENI for a DSO Keepalive request message, because the Keepalive TLV is mandatory to implement.
  • Section 5.4.1: if a DSO response message is received where the MESSAGE ID is zero, that is a fatal error and the recipient MUST forcibly abort the connection immediately.

Read those in sequence. A session exists only by mutual establishment. A named refusal code is unavailable for one specific request because something else is mandatory. A malformed identifier is not a warning but a termination. Two machines now hold a joint state that neither can unilaterally declare into being, and the document is where that jointness is written down.

Around the prohibitions sits discretion, and the drafters marked it as such. A client that receives no response SHOULD wait 30 seconds. A client whose server drops the connection SHOULD mark that service instance as not supporting DSO. These are instructions about how to interpret silence, which is a different kind of guidance from how to constitute a session.

What the record does not settle

Two natural follow-up questions do not have answers in the material reviewed for this article, and it is worth being exact about why.

First, the correction record. When checked on 18 October 2026, the RFC Editor errata pages displayed no entries for RFC 5625 or RFC 8490, and neither information page indicated an obsoleting or successor document. An empty errata display is a weak signal, not a strong one: it can mean a document has held up, or that nobody has filed a correction, which are different facts that look identical from the outside.

Second, the production record. The IETF Datatracker records for RFC 5625 and RFC 8490 were available here as page summaries rather than as full revision histories, so which draft changed which sentence, and which review preceded which revision, is only partly visible. The working group lineage is recorded — DNSEXT for the proxy guidance, DNSOP for stateful operations — but the edit-by-edit story is not.

Third, and most important, no implementation evidence was obtained for either document. This article therefore makes no claim that RFC 5625 changed how gateways forward queries, or that DSC or DSO appears in any shipping resolver. Those are empirical questions about software, and software left no trace in the record examined here.

Where authorship actually ends

The temptation with a person like Bellis is to read the RFC number as evidence of the network. It is not. The number records that a document was published, reviewed and catalogued; it says nothing about which machines run what it describes. Compliance appears in deployment, and deployment is somebody else's decision.

What the author demonstrably controlled is narrower and more interesting. He controlled the wording: which obligation became a MUST, which became a RECOMMENDED, and — in RFC 5625 especially — whether the document's strongest verbs would be spent forbidding damage or demanding features. He controlled, with five co-authors, the choice to make session establishment a precondition rather than a courtesy. Those are real acts, attributable to named people, and they are visible in the text.

What he did not control is the part that decides whether any of it matters. An implementer can read RFC 8490, weigh the cost of session state against a firmware schedule, and decline. Nothing in the document reaches them. The registry holds the number anyway, which is precisely why the registry is a better witness to durability than the prose is to adoption.