| Internet-Draft | External-Registry RRTYPEs | August 2026 |
| Woodcock & Fältström | Expires 15 February 2027 | [Page] |
This document defines two DNS resource record types, UNECE and ISO, which convey numeric values paired with codes drawn from registries maintained by external standards organizations: the United Nations Economic Commission for Europe (UNECE) and the International Organization for Standardization. Neither proposed RRTYPE duplicates the external registries into IANA registries; each carries codes verbatim and uses the semantics defined by the external maintainer. The document specifies presentation and wire formats for both types, requests the assignment of two decimal RRTYPE identifiers under the Expert Review process of BCP 42, and suggests a common design pattern that may serve as a model for future RRTYPEs seeking to make external registries usable from the DNS without duplication.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-woodcock-faltstrom-external-registry-rrtypes/.¶
Discussion of this document takes place on the DNSOP Working Group mailing list (mailto:dnsop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Subscribe at https://www.ietf.org/mailman/listinfo/dnsop/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 15 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Many protocols need to convey data whose controlled vocabularies are defined and maintained outside the IETF, including but not limited to quantities, countries, languages, locations, and units of measure. The authoritative registries of these vocabularies are external standards organizations. The two referenced in this document are the United Nations Economic Commission for Europe (UNECE) and the International Organization for Standardization (ISO).¶
The DNS has historically accommodated such data in one of two ways. Either the external registry is duplicated into an IANA registry, creating a synchronization burden and a second claimant to authority over the code space, as the IANA Language Subtag Registry [BCP47] replicates ISO and UN code lists, and as IANA's IEEE 802 Numbers registry partially mirrors IEEE Registration Authority assignments; or the data is carried in TXT records under private convention, forfeiting type-distinct queries, field structure, and single-RRset signing.¶
This document defines two resource record types which take a different path: the RDATA carries a discriminator identifying the registry, an optional numeric value, the registry code point, and an optional free-text descriptor. Semantics of the code remain entirely with the external maintainer; unrecognized codes are carried and displayed rather than rejected, so that the RRTYPEs track the external registries without protocol changes or IANA registry actions. The approach has precedent in e164.arpa [RFC6116], whose ENUM delegations are keyed to ITU-T E.164 country-code assignments without maintaining a local copy, leaving authority with the external registry.¶
The immediate motivation for these RRTYPEs is the work currently being done in the DIEM working group on Digital Emblems, which convey cryptographically signed record-bundles identifying assets marked under international law. The proposed RRTYPEs are, however, general-purpose and intended for use by other applications which need to represent standardized data formats maintained by external registries.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The standards organization which defines and revises external registries. The code space belongs to the External Maintainer; nothing in this document, and no issuer of records, creates, modifies, or retires codes.¶
The party publishing records in a DNS zone.¶
Any party retrieving or interpreting the resource records.¶
RRTYPEs following this pattern conform to all of the following. The UNECE (Section 3) and ISO (Section 4) types are initial instantiations.¶
A single RRTYPE covers all of an External Maintainer's registries; a Discriminator field in the RDATA specifies the particular registry. Per-registry RRTYPEs are not defined.¶
The Code field carries the code exactly as published by the External Maintainer, and is compared octet-for-octet, with no case folding. Issuers MUST NOT coin codes. Codes contain no whitespace: where a maintainer's published rendering separates a code's components with whitespace, the separator is presentation rather than part of the code, and the code is the concatenation.¶
A Receiver encountering an unrecognized Discriminator MUST carry and display the record without interpretation. A Receiver encountering an unrecognized code within a recognized list MUST display it uninterpreted and MUST NOT treat the record as invalid. These rules allow the type to track the external registry without IANA registry action or protocol changes.¶
An Issuer MUST NOT publish a DNS Resource Record referencing a registry whose code list is not currently active and publicly available at no cost and citable at the time of RR publication. This precludes code lists which have not yet been published as official work-products of their respective External Maintainer organizations, code lists which require subscriptions to access or which carry prohibitive use restrictions, and those which have been withdrawn or superseded.¶
IANA action is limited to the RRTYPE code point. No IANA subregistry duplicating the external registries is created; specifications instead cite each external registry as its current revision or its successor.¶
The optional numeric Value field uses the shared grammar and semantics of Section 2.3, including its distinction between an inapplicable quantity and an unknown one.¶
The optional Descriptor field is free text identifying what the datum describes relative to the subject. It is a display and matching hint for human receivers, and MUST NOT be interpreted as machine semantics.¶
RDATA contains no domain names, and requires no compression, rewriting, or additional-section processing, so the RRTYPEs are fully compatible with unknown-type handling [RFC3597].¶
Where records appear in DNSSEC-signed zones and historical accuracy matters, Receivers SHOULD interpret codes against the registry revision in force at the inception time of the covering RRSIG [RFC4034] [RFC9364]. Where an External Maintainer retains deleted codes in its published lists, as UNECE Recommendation 20 does [UNECE20], locally cached code tables remain safe.¶
If a record utilizes a code which does not require a quantity, the Value is not applicable (na): empty, zero-length on the wire, the solitary token "-" in presentation. This is the same representation used for an empty Salt field in NSEC3 and NSEC3PARAM [RFC5155]. A Value field MUST NOT consist solely of the octet "-"; the zero-length field is na's only wire encoding.¶
Values are represented in US-ASCII in this grammar, using ABNF [RFC5234] and its core rule DIGIT:¶
value = unknown / quantity
unknown = "?"
quantity = ( "0" / ["-"] posnum ) [precision]
precision = "(" ( "0" / posnum / "?" ) ")"
posnum = nzint [ "." frac ] / "0" "." frac
nzint = %x31-39 *DIGIT
frac = *DIGIT %x31-39
¶
A quantity attaches to this record, but is unknown to the Issuer at the time of RR creation or signing.¶
The number, in the units or terms of the code. The parenthetical precision is plus-or-minus that amount in the same units; "(?)" marks the precision unknown. A precision attached to an unknown value ("?(n)") is not permitted.¶
The grammar admits exactly one representation of each number: leading zeros, trailing zeros in a fractional part, all-zero fractional parts, and negative zero cannot be represented. Non-zero negative values are permitted.¶
A Receiver encountering a nonempty Value which does not match the grammar MUST display it uninterpreted without deriving a quantity, and MUST NOT treat the record as invalid.¶
The distinction between "-" and "?" is semantic and deliberate: the former states that no quantity exists to be reported, the latter that one exists and is unreported.¶
The UNECE RRTYPE conveys a value coded according to a registry published in the UNECE Recommendations series.¶
The wire format of the RDATA field [RFC1035] is as follows:¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rec. Length | Recommendation /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Length | Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code Length | Code /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Descriptor /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Fields marked "/" are variable length.¶
an 8-bit unsigned integer, which MUST be nonzero.¶
<Recommendation Length> octets, US-ASCII: a token identifying the Recommendation from whose code list the Code field is drawn. The token is the Recommendation's identifier with the words "Recommendation No." omitted: "20" for Recommendation No. 20. Tokens are not necessarily numeric: a future "Recommendation No. 3bis" would yield the token "3bis". "UNECE" is omitted because the RRTYPE itself names the organization; edition years, amendments, and corrigenda are omitted to preserve forward compatibility under the temporal-anchoring principle of Section 2.2. Tokens contain no whitespace and are compared octet-for-octet with no case folding. Issuers MUST use tokens exactly as the rule yields them, neither coining nor reformatting.¶
an 8-bit unsigned integer.¶
<Value Length> octets, US-ASCII, matching the value grammar of Section 2.3. A length of zero encodes na, and is its only wire encoding.¶
an 8-bit unsigned integer, which MUST be nonzero.¶
<Code Length> octets, US-ASCII, verbatim from the cited Recommendation's registry.¶
all remaining octets of the RDATA, UTF-8 [RFC3629], possibly empty, but at most 255 octets in total. A Receiver encountering a longer Descriptor MUST NOT treat the record as invalid.¶
The presentation format is:¶
UNECE <rec> <value> <code> ["<descriptor>"]¶
where <rec> is the Recommendation token per Section 3.1; <value> is the Value token per Section 2.3, with the zero-length wire value presented as "-"; <code> is the Code, unquoted; and the Descriptor, if present, is a single quoted <character-string> per Section 5.1 of [RFC1035], its embedded quotes, backslashes, and non-ASCII octets escaped by that section's "\X" and "\DDD" conventions.¶
The applicable Recommendations are those whose registries UNECE itself publishes [UNECE-CL][UNECE20][UNECE21]. At the time of writing, these include:¶
16 United Nations Code for Trade and Transport Locations
17 Payment terms abbreviations
19 Codes for modes of transport
20 Codes for units of measure used in international trade
21 Codes for passengers, types of cargo, packages and
packaging materials
23 Freight cost codes
24 Trade and transport status codes
28 Codes for types of means of transport
¶
A Recommendation 16 code is the five-character concatenation of the ISO 3166-1 country code and the location code; the space separating them in UNECE's published tables is not part of the code: "JPTYO", not "JP TYO".¶
UNECE, through its United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), maintains and publishes these code lists free of charge [UNECE-CL]. The code-list Recommendations are maintained on UN/CEFACT's behalf by its Information Content Management Group, and the Recommendation 16 code list, UN/LOCODE, is updated by the UNECE secretariat twice a year. Deleted and deprecated code values are marked as such in the published lists rather than removed, so that a code value, once assigned, remains permanently attached to its original meaning [UNECE20].¶
Recommendations which adopt externally maintained standards are out of scope for this type: Recommendation 3 (ISO 3166), Recommendation 9 (ISO 4217; see the ISO RRTYPE, Section 4), and Recommendation 5 (Incoterms, maintained by the International Chamber of Commerce). Recommendation 10 (ship identification) adopts the IMO Ship Identification Number Scheme, whose numbers appear as identifiers rather than as coded values.¶
@ IN UNECE 16 - JPTYO "place of inspection" @ IN UNECE 16 - KENBO "distribution hub" @ IN UNECE 19 - 1 "mode: maritime" @ IN UNECE 19 - 4 "mode: air" @ IN UNECE 20 640 H18 "protected wetland area" @ IN UNECE 20 12500 MTQ "reservoir volume" @ IN UNECE 20 5 MGM "active ingredient per dose" @ IN UNECE 20 8500 E22 "container capacity, TEU" @ IN UNECE 20 -18 CEL "cold-chain storage temperature" @ IN UNECE 20 90 DAY "shelf life" @ IN UNECE 20 24 MON "warranty period" @ IN UNECE 20 230 VLT "supply voltage" @ IN UNECE 20 11 KWT "charger output" @ IN UNECE 20 ? P1 "moisture content, assay pending" @ IN UNECE 21 12 PX "pallets" @ IN UNECE 21 2 CR "crates, artworks on loan" @ IN UNECE 21 3 RL "reels, fibre-optic cable" @ IN UNECE 21 2 PO "diplomatic pouches" @ IN UNECE 24 - 219 "status: delivery pending"¶
Receivers apply the rules of Section 2.2. In particular, a Receiver encountering a Recommendation token it does not recognize carries and displays the record uninterpreted, and a Receiver encountering a code it does not recognize displays the code uninterpreted without treating the record as invalid.¶
The ISO RRTYPE conveys a value coded by a registry defined in a standard of the International Organization for Standardization.¶
The wire format of the RDATA field [RFC1035] is as follows:¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Standard Length| Standard /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Length | Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code Length | Code /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Descriptor /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Fields marked "/" are variable length.¶
an 8-bit unsigned integer, which MUST be nonzero.¶
<Standard Length> octets, US-ASCII: a token identifying the standard from whose code list the Code field is drawn. The token is the standard's identifier, including any hyphen-joined part and sub-part identifiers: "3166-1" for ISO 3166-1. Where the identifier carries a type prefix (such as TR, TS, PAS, IWA, or Guide), the prefix is joined with an underscore: for example, "TR_24028" for ISO/IEC TR 24028, or "Guide_2" for ISO/IEC Guide 2. "ISO" and "ISO/IEC" are omitted because the RRTYPE itself names the organization; edition years, amendments, and corrigenda are omitted to preserve forward compatibility under the temporal-anchoring principle of Section 2.2. Tokens contain no whitespace and are compared octet-for-octet with no case folding. Issuers MUST use tokens exactly as the rule yields them, neither coining nor reformatting.¶
an 8-bit unsigned integer.¶
<Value Length> octets, US-ASCII, matching the value grammar of Section 2.3. A length of zero encodes na, and is its only wire encoding.¶
an 8-bit unsigned integer, which MUST be nonzero.¶
<Code Length> octets, US-ASCII, verbatim from the cited standard. For ISO 3166-1, alpha-2 codes are RECOMMENDED, for consistency with UNECE Recommendation 3 and general DNS practice. For ISO 4217, the alphabetic codes are RECOMMENDED over the numeric, for consistency with UNECE Recommendation 9. For ISO 639, two-letter (Set 1) identifiers are RECOMMENDED where they exist.¶
all remaining octets of the RDATA, UTF-8 [RFC3629], possibly empty, but at most 255 octets in total. A Receiver encountering a longer Descriptor MUST NOT treat the record as invalid.¶
The presentation format is:¶
ISO <standard> <value> <code> ["<descriptor>"]¶
where <standard> is the Standard token per Section 4.1; <value> is the Value token per Section 2.3, with the zero-length wire value presented as "-"; <code> is the Code, unquoted; and the Descriptor, if present, is a single quoted <character-string> per Section 5.1 of [RFC1035], its embedded quotes, backslashes, and non-ASCII octets escaped by that section's "\X" and "\DDD" conventions.¶
Applicable standards are those defining registries of code lists; initially:¶
639 Language codes 3166-1 Country codes 3166-2 Country subdivision codes 4217 Currency codes¶
ISO permits use of its country, currency, and language codes free of charge [ISO4217], and each code list is maintained by a body designated for its standard: the ISO 3166 Maintenance Agency for country and subdivision codes [ISO3166], SIX Financial Information for currency codes [ISO4217], and the ISO 639 Maintenance Agency for language codes [ISO639]. Retirement practices vary by registry. A deleted ISO 3166-1 alpha-2 code element is recorded in ISO 3166-3 and cannot be reused for fifty years under current policy, but reassignment has occurred. Withdrawn ISO 4217 codes are retained, with their withdrawal dates, in that standard's list of historic currencies. Retired ISO 639 identifiers are never reassigned; they remain in the code set permanently.¶
Out of scope: ISO 8601, which defines a format rather than a code list (temporal data uses a separate mechanism); ISO 6346, whose container owner codes appear within asset identifiers; and ISO 15924, whose script codes travel within BCP 47 [BCP47] language tags inside textual elements.¶
@ IN ISO 639 - ar "working language" @ IN ISO 639 - yue "crew lingua franca" @ IN ISO 3166-1 - QA "flag state" @ IN ISO 3166-2 - US-CA "state of incorporation" @ IN ISO 4217 125000 USD "declared cargo value" @ IN ISO 4217 2400000(50000) EUR "insured value, hull and machinery" @ IN ISO 4217 780000(?) CHF "salvage award, assessment ongoing" @ IN ISO 4217 ? ZAR "customs value pending appraisal"¶
Receivers apply the rules of Section 2.2. In particular, a Receiver encountering a standard token it does not recognize carries and displays the record uninterpreted, and a Receiver encountering a code it does not recognize displays the code uninterpreted without treating the record as invalid.¶
This document is intended as the model for future RRTYPEs which make external registries usable from the DNS without duplicating their content. Sections 3.3 and 4.3 record the corresponding information for the two types defined here. A specification defining such a type:¶
identifies the External Maintainer, demonstrates that its registries are managed with a sufficient level of maturity, stably published and citable, and states the maintainer's code-retirement policy (reassignment of retired codes weakens the temporal-anchoring rule of Section 2.2 and SHOULD be documented if present);¶
defines a single RRTYPE for the maintainer's whole series, discriminated by a length-prefixed US-ASCII token deterministically formed from the External Maintainer's own identifier for the defining document;¶
reuses the Value field grammar and semantics of Section 2.3 verbatim, so that implementations share one parser across all types following this pattern;¶
carries codes verbatim with octet-for-octet comparison, and prohibits issuers from coining codes;¶
adopts the unknown-value carriage rules of Section 2.2 unchanged;¶
requests only an RRTYPE code point from IANA, creating no mirror subregistry; and¶
keeps domain names out of the RDATA, preserving RFC 3597 compatibility.¶
One possible additional instantiation is an RRTYPE for the World Customs Organization registries, carrying Harmonized System subheadings for the description of goods; the pattern accommodates it without modification.¶
Records of these types assert data under the containing zone's DNSSEC signatures; they confer no authorization, and their trustworthiness is the same as that of the zone's signing chain.¶
Issuers should consider anything published in the DNS to be public unless specific selective-disclosure measures are taken to constrain distribution. Such measures are out of scope for this document.¶
Because the code travels verbatim in RDATA, a revision of the external registry cannot alter published signed data. It can, however, change what a Receiver understands a code to mean. Where the External Maintainer never reassigns retired codes, cached tables are safe indefinitely; where that policy is absent, Receivers SHOULD apply the temporal-anchoring rule of Section 2.2, interpreting codes against the registry revision in force at the inception time of the covering RRSIG.¶
The Descriptor is untrusted free text. Receivers MUST NOT derive machine behavior from it, and display implementations SHOULD sanitize it as they would any untrusted text, removing control and other hazardous characters.¶
The "?" token is an assertion of ignorance made under signature. Relying parties should treat it as exactly that: evidence that the Issuer disclaimed knowledge at signing time, not as a zero value nor as an omission.¶
This document requests the assignment of two new decimal RRTYPE identifiers, following the guidelines of [RFC6895] (BCP 42).¶
IANA is requested to add the following entries to the "Resource Record (RR) TYPEs" registry in the "Domain Name System (DNS) Parameters" registry group:¶
| TYPE | Value | Meaning | Reference |
|---|---|---|---|
| UNECE | TBD1 | Value coded per a UNECE Recommendation | [this document] |
| ISO | TBD2 | Value coded per an ISO standard | [this document] |
[RFC Editor: replace TBD1 and TBD2 with the decimal values assigned by IANA, and remove this note.]¶
RRTYPE identifiers are assigned under the DNS RRTYPE Allocation Policy of Section 3.1 of [RFC6895], an Expert Review process [RFC8126] conducted on the basis of completed application templates conforming to the template of [RFC6895]. Completed templates for both types defined here have been submitted separately to dns-rrtype-applications@ietf.org. Assignment via Expert Review MAY complete in advance of the publication of this document, in which case IANA is requested to update the registry references for both entries to point to this document upon its publication.¶