Summary

  • Revision 01 of an individual Internet-Draft records two DNS resource-record assignments completed by Expert Review on 20 August 2026: UNECE is decimal type 69 and ISO is type 70. The codepoints are live in IANA's registry, but the draft is not an RFC or a DNSOP working-group document.
  • The RDATA carries an external standard or recommendation token and a code verbatim, while edition years are intentionally omitted. The draft points receivers to the external registry revision in force at RRSIG inception when history matters; the signature itself does not identify or hash that revision.

The IANA DNS Parameters registry now has two adjacent entries that look deceptively complete. Type 69 is UNECE, for a value coded under a United Nations Economic Commission for Europe recommendation. Type 70 is ISO, for a value coded under an International Organization for Standardization standard. Both entries are dated 20 August 2026 and link to separate Expert Review applications.

The allocation is real. The specification is still moving.

Revision 01 of draft-woodcock-faltstrom-external-registry-rrtypes was uploaded on 9 September. Its appendix and the official revision comparison say that the sole change from revision 00 is to record the two assignments and the Expert Review completed on 20 August. The Datatracker record and machine-readable entry identify it as an active individual Internet-Draft. Its header proposes Standards Track. It has no RFC number, stream or responsible Area Director, and its history does not turn codepoint allocation into working-group adoption.

That separation matters because RFC 6895 places DNS RRTYPE assignment under Expert Review. RFC 8126 describes Expert Review as judgment by designated experts against the applicable criteria. It is a controlled allocation path, not a substitute for later consensus or RFC publication. The public UNECE application and ISO application explain why the numbers were needed and how unknown-type processing remains possible.

IANA owns the envelope, not the vocabulary

The draft's most important governance choice is negative: it creates no IANA mirror of UNECE or ISO code lists. IANA assigns the DNS type. UNECE or ISO and their designated maintenance bodies continue to define the codes carried inside it. A zone issuer publishes a record. A receiver interprets it. Those roles do not collapse merely because one signed RRset contains the result.

For UNECE, the record names a Recommendation such as 16 for UN/LOCODE or 20 for units of measure. For ISO, it names a standard such as 3166-1, 4217 or 639. The code is copied verbatim and compared octet for octet. An issuer must not invent a code. A receiver that does not recognise a discriminator or code must carry and display it without interpretation rather than call the record invalid.

This design avoids a second claimant to authority. The UNECE code-list surface can remain the publication point for UNECE recommendations, and the ISO 3166 surface remains part of ISO's own maintenance structure. RFC 6116 supplies an earlier pattern: ENUM uses E.164 country-code assignments without recreating the numbering authority inside IANA.

The price of that restraint is a live dependency. A valid DNS record can outlast the page, table or edition that an operator consulted when it interpreted the code. Authority stays external, so evidentiary continuity must cross an institutional boundary.

Forward compatibility removes the edition from the record

The UNECE Recommendation token and ISO Standard token omit edition years, amendments and corrigenda. The same ISO 3166-1 or UNECE 20 discriminator is supposed to survive later maintenance. That is useful for wire stability. It also means the RDATA does not say “the 2026 edition” or identify a particular archive object.

The draft compensates with eligibility and time rules. At publication, the referenced code list must be active, publicly available without charge and citable. Future specifications following the pattern should document the maintainer's retirement and reassignment policy. The examples show why: deleted UNECE values are said to remain in published lists; withdrawn ISO 4217 currencies retain withdrawal dates; retired ISO 639 identifiers are not reassigned; ISO 3166 has a reservation period but has seen reassignment.

These are different continuity models. “Code unchanged” can mean permanently stable, historically reserved, currently valid, withdrawn but traceable, or later reused. The DNS field does not decide among them.

RRSIG inception is a clock, not an edition identifier

When historical accuracy matters, the draft tells receivers to interpret the code against the registry revision in force at the inception time of the covering RRSIG. That is a sensible coordinate. It does not close the evidence chain by itself.

RFC 4034 defines Signature Inception as the earliest time at which an RRSIG may be used to authenticate its covered RRset. The RRSIG also carries expiration, algorithm, key tag, signer and the cryptographic signature. It carries no UNECE release number, ISO edition, external URL or registry digest. RFC 9364 places those fields inside DNSSEC's data-origin authentication and integrity system; it does not make DNSSEC an external standards archive.

A zone can also re-sign unchanged RDATA. The new RRSIG inception changes even though the external code and the issuer's assertion did not. Conversely, an external registry can publish a revision while an older signed RRset remains valid. The timestamp helps a receiver choose a point on a line. It does not prove which external artifact the receiver actually found at that point.

This is not a defect report. No source here shows a wrong interpretation or failed deployment. It is a boundary created by a deliberate division of authority.

Preserve the interpretation that produced the decision

The minimum operational addition is a local external-registry resolution receipt. It should record the RRTYPE, discriminator, raw value and raw code; external maintainer; exact registry edition when one exists, otherwise the retrieval URI, retrieval time and content digest; RRSIG inception, expiration, signer and validation result; retirement or reassignment rule applied; whether the value was unknown; issuer policy version; and the local decision that consumed the interpretation.

The receipt must not pretend to certify the external registry. It says which evidence a receiver used. If the external source later moves, a digest and permitted archival copy can show what was read. If a code is retired or reassigned, the applied policy is visible. If an unchanged RRset is re-signed, the record does not silently acquire a new semantic history.

This follows the restraint in Heng Lu's Minimum Initial Specification: make the smallest shared reliance boundary deterministic and leave policy and implementation local. The Policy Mirror adds the requirement that a consequential automated result remain reconstructable from rule, authority and evidence. Neither essay requires these DNS fields; the receipt is my proposal.

Revision 01 has made the outer allocation concrete. Responsible use now depends on preserving the equally concrete external version that supplied the inner meaning.

Sources