Summary

  • RFC 5395 did not treat DNS's 16-bit fields as undifferentiated space. Header bits, RCODEs, data TYPEs, QTYPEs, Meta-TYPEs and CLASSes carried different allocation procedures and compatibility risks.
  • Unassigned, reserved and Private Use are distinct states. Private Use allows local meaning but deliberately supplies no collision-free global identity; an unassigned value still needs the applicable allocation action.
  • A complete audit keeps the field and wire context, number, authority path, dated registry row, implementation behavior, peer interpretation and user outcome as separate receipts.

The blank row answered only one question

An unassigned row answers: “Has this registry recorded an assignment here?” It does not answer who may assign the value, under what procedure, for which semantic class, or whether a private experiment may escape its intended boundary. RFC 5395 mapped those questions across DNS rather than declaring one universal rule.

The document covered OpCodes, RCODEs, header bits, resource-record types, CLASSes and AFSDB subtypes. Each field had its own scarcity, compatibility history and review policy. A value available for assignment could require Standards Action, IETF Review or Expert Review. A reserved value carried a stronger prohibition. A Private Use range delegated meaning to a local site while withholding global uniqueness.

That vocabulary matters in incident review. “We selected an unused number” describes an observation, not an authorization. “The parser accepted it” describes implementation behavior, not registry state. “The lab peer understood it” describes one bilateral convention, not Internet-wide semantics. Combining all three into “the code point is supported” makes the evidence less precise exactly when systems begin to interconnect.

RFC 5395 is now historical rather than current. RFC 6195 replaced it in 2011, largely to change the public review list. RFC 6895 replaced RFC 6195 in 2013, streamlined the RRTYPE process and closed the AFSDB subtype registry. The live IANA DNS Parameters registry is the current frozen state for this commission. A 2008 table is provenance for the policy architecture, not a 2026 inventory.

Sixteen meant BADVERS or BADSIG, depending on where it stood

DNS error numbers demonstrate why the number alone is an incomplete identity. An RCODE can appear in the DNS header and in OPT, TSIG or TKEY records. OPT extends the effective width. RFC 5395 listed error 16 as BADVERS for an unsupported OPT version and as BADSIG for a TSIG signature failure.

RFC 6895 retained that contextual exception and documented a second one for error 9: “Not Authoritative” in one response context, “Not Authorized” in another involving TSIG. It otherwise required error numbers not to acquire different meanings merely because they occur in different RR types.

A monitor that stores only rcode=16 has discarded the evidence that decides the diagnosis. A counter can be arithmetically correct and operationally ambiguous. The receipt needs the base header or extended field, the containing record, the effective width, the peer and the governing specification. Without those dimensions, a security team can investigate a protocol-version problem as a signature failure, or the reverse.

The same rule applies beyond error codes. A database column named code invites false joins across registries. Value 16 in one namespace is not an alias for value 16 in another. Numeric equality is not semantic identity; the registry name and field position are part of the key.

The supposedly spare bit already had a history

The DNS header diagram appeared to leave room. Yet RFC 5395 warned that some implementations initialized a response by copying the query header without clearing bits. A bit theoretically meaningful only in a query could therefore return in a response. Giving that returned bit a different response meaning would make inherited state look like a deliberate signal.

The Z bit carried an even older shadow. Some ancient implementations treated it in a query as a demand for an answer from the primary server. RFC 5395 believed current implementations ignored that behavior, but still required Standards Action before assigning a meaning.

This is not proof that every current server copies every bit. It is a design boundary: field diagrams do not contain the full installed state of a protocol. Historical behavior can occupy an apparently vacant surface. The allocation procedure forces the claim into public review because a private implementation inventory cannot prove that all deployed parsers are harmless.

The governing lesson is uncomfortable for fast-moving engineering teams. A spare bit is not owned by whoever ships first. Running code is necessary evidence, but one implementation's success cannot extinguish unknown behavior in other implementations. The decision needs both a protocol authority path and real interoperability testing.

Private Use is a boundary, not a miniature public registry

The RRTYPE Private Use range is 65280 through 65534. A site may assign meanings there without IANA recording them. RFC 8126 explains the bargain: IANA does not prevent different sites from choosing the same value in incompatible ways, and the sites are responsible for avoiding conflicts within their intended scope.

Suppose two companies independently choose 65300. One means a service-health assertion; the other means a policy token. Each convention can work perfectly inside its own laboratory. When the networks merge, a gateway or shared resolver may see identical type numbers carrying incompatible RDATA. There is no global registry row that decides which private meaning wins, because absence of that coordination is the defining property of Private Use.

The correct operational response is not to forbid private values. It is to name and enforce their boundary. Record the participating systems, expected lifetime, collision domain, escape controls and teardown plan. If broad interoperation becomes a requirement, obtain an assignment through the appropriate procedure rather than treating installed private usage as ownership by precedent.

Unassigned is different again. It means the registry has not assigned a public meaning. Selecting from that pool without authorization can collide with a later legitimate assignment. Private Use at least marks an area where local collision responsibility is explicit. A random unassigned value merely borrows future registry space without a contract.

Expert Review allocated a name; it did not deploy the feature

RFC 5395 introduced a DNS-specific RRTYPE allocation policy based on Expert Review. RFC 6895 streamlined it. The applicant supplies a complete template; IANA appoints an expert; the expert approves or rejects and explains rejection; approved templates enter a public archive.

The technical threshold is deliberately about safe extension. A proposed data TYPE must be handleable as an unknown RR under RFC 3597, or a proposed Meta-TYPE must be optional to process and safe to discard. The expert should reject unclear proposals, proposals built on incorrect DNS assumptions, proposals whose processing breaks those conditions, or requests for more values than necessary.

Approval proves that an allocation decision occurred under that procedure. It does not prove that authoritative servers accept the presentation format, that secondaries transfer it, that provisioning systems preserve it, that resolvers expose it, that applications understand it, or that the intended service works. Those are later receipts.

The separation protects both sides. The registry need not wait until every vendor ships before reserving a collision-free identity. Operators must not present the reserved identity as evidence of deployed capability. A completed template is a specification record; a packet capture and application result are execution records.

Opaque bytes can survive without producing meaning

RFC 3597 gave unknown RRs a generic textual representation: TYPE followed by the decimal number, then \#, an octet length and hexadecimal RDATA. It also constrained compression and equality so servers could store, transfer and compare unfamiliar records without corrupting them.

That capability is one of DNS's most valuable extension mechanisms. It allows infrastructure to preserve data before every intermediary understands the new type. But byte preservation is not semantic execution. A secondary that transfers an unknown RR intact has demonstrated custody. A resolver that returns it has demonstrated retrieval. Neither has demonstrated that an application validated or acted on its contents.

This distinction becomes visible in testing. A round trip can succeed while a user-facing feature remains absent. Conversely, a provisioning front end can recognize the mnemonic yet serialize the RDATA incorrectly. The audit therefore needs separate checks for source parsing, wire encoding, transfer, cache, API exposure, application interpretation and final outcome.

RFC 3597 also says that a known type written in generic form must still receive its type-specific processing after parsing. Representation cannot be used to demote known semantics into harmless opacity. The parser's route into memory and the later execution path are different stages of one receipt.

The current registry is a dated state, not timeless truth

The frozen IANA page for this research reports an update date of 28 August 2026 and contains assignments that did not exist in RFC 5395. It also marks obsolete, deprecated, unassigned, reserved and private ranges. That is what a maintained operational registry should do: preserve identity while allowing status and references to evolve.

An audit must therefore record which snapshot supported a decision. “According to RFC 5395” may be historically exact and currently incomplete. “According to IANA” is also incomplete without the registry name and retrieval time. A cached CSV, a generated YANG module and the web table can drift if a synchronization job fails; their agreement should be measured, not assumed.

The durable identity is not one document. It is a governed chain: the RFC that created or revised the policy, the later RFC that changed it, the IANA action that recorded an assignment, and the implementation evidence that used it. Removing any link encourages a different false conclusion—timelessness, authority without action, or action without authority.

Evidence boundary

The frozen sources prove the texts and status succession of RFCs 5395, 6195 and 6895, the generic unknown-RR rules in RFC 3597, the general registry vocabulary in RFC 8126, and the IANA table as captured. They do not prove present support in a named DNS product, adoption by an operator, a collision incident, or the cause of an outage.

The strongest conclusion is narrow. A DNS code point becomes usable at several different moments: when a local experiment chooses it, when the relevant authority assigns it, when IANA records it, when implementations preserve it, when applications understand it and when users obtain the intended result. One number can pass some of those moments and fail the others. Leadership should ask which receipt exists, not whether one dashboard says “registered.”