]> PCH

woody@pch.net

Netnod

paf@netnod.se

Network Working Group 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, records 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. Status information for this document may be found at . Discussion of this document takes place on the DNSOP Working Group mailing list (), which is archived at . Subscribe at .

Introduction 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 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 , 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.

Conventions 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 when, and only when, they appear in all capitals, as shown here.

The External Registry Pattern

Roles

External Maintainer:

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.

Issuer:

The party publishing records in a DNS zone.

Receiver:

Any party retrieving or interpreting the resource records.

Design Principles RRTYPEs following this pattern conform to all of the following. The UNECE () and ISO () types are initial instantiations.

One type per maintainer organization:

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.

Codes verbatim:

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.

Unknown values carried:

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.

Registries must be at a valid stage:

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.

No mirror registries:

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.

Common value grammar:

The optional numeric Value field uses the shared grammar and semantics of , including its distinction between an inapplicable quantity and an unknown one.

Descriptor as hint:

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.

RFC 3597 cleanliness:

RDATA contains no domain names, and requires no compression, rewriting, or additional-section processing, so the RRTYPEs are fully compatible with unknown-type handling .

Temporal anchoring:

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 . Where an External Maintainer retains deleted codes in its published lists, as UNECE Recommendation 20 does , locally cached code tables remain safe.

The Value Field 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 . 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 and its core rule DIGIT:

"?" (unknown):

A quantity attaches to this record, but is unknown to the Issuer at the time of RR creation or signing.

quantity:

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 The UNECE RRTYPE conveys a value coded according to a registry published in the UNECE Recommendations series.

Wire Format The wire format of the RDATA field is as follows:

Fields marked "/" are variable length.

Recommendation Length:

an 8-bit unsigned integer, which MUST be nonzero.

Recommendation:

<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 . 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.

Value Length:

an 8-bit unsigned integer.

Value:

<Value Length> octets, US-ASCII, matching the value grammar of . A length of zero encodes na, and is its only wire encoding.

Code Length:

an 8-bit unsigned integer, which MUST be nonzero.

Code:

<Code Length> octets, US-ASCII, verbatim from the cited Recommendation's registry.

Descriptor:

all remaining octets of the RDATA, UTF-8 , possibly empty, but at most 255 octets in total. A Receiver encountering a longer Descriptor MUST NOT treat the record as invalid.

Presentation Format The presentation format is:

[""] ]]>

where <rec> is the Recommendation token per ; <value> is the Value token per , 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 , its embedded quotes, backslashes, and non-ASCII octets escaped by that section's "\X" and "\DDD" conventions.

Applicable Recommendations The applicable Recommendations are those whose registries UNECE itself publishes . At the time of writing, these include:

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 . 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 . 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, ), 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.

Examples

Processing Receivers apply the rules of . 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 The ISO RRTYPE conveys a value coded by a registry defined in a standard of the International Organization for Standardization.

Wire Format The wire format of the RDATA field is as follows:

Fields marked "/" are variable length.

Standard Length:

an 8-bit unsigned integer, which MUST be nonzero.

Standard:

<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 . 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.

Value Length:

an 8-bit unsigned integer.

Value:

<Value Length> octets, US-ASCII, matching the value grammar of . A length of zero encodes na, and is its only wire encoding.

Code Length:

an 8-bit unsigned integer, which MUST be nonzero.

Code:

<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.

Descriptor:

all remaining octets of the RDATA, UTF-8 , possibly empty, but at most 255 octets in total. A Receiver encountering a longer Descriptor MUST NOT treat the record as invalid.

Presentation Format The presentation format is:

[""] ]]>

where <standard> is the Standard token per ; <value> is the Value token per , 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 , its embedded quotes, backslashes, and non-ASCII octets escaped by that section's "\X" and "\DDD" conventions.

Applicable Standards Applicable standards are those defining registries of code lists; initially:

ISO permits use of its country, currency, and language codes free of charge , and each code list is maintained by a body designated for its standard: the ISO 3166 Maintenance Agency for country and subdivision codes , SIX Financial Information for currency codes , and the ISO 639 Maintenance Agency for language codes . 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 language tags inside textual elements.

Examples

Processing Receivers apply the rules of . 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.

Defining Additional External-Registry RRTYPEs This document is intended as the model for future RRTYPEs which make external registries usable from the DNS without duplicating their content. Sections and 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 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 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 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.

Security Considerations 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 , 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.

IANA Considerations This document records the assignment of two new decimal RRTYPE identifiers, made following the guidelines of (BCP 42).

RRTYPE Assignments IANA has added the following entries to the "Resource Record (RR) TYPEs" registry in the "Domain Name System (DNS) Parameters" registry group: TYPE Value Meaning Reference UNECE 69 Value coded per a UNECE Recommendation [this document] ISO 70 Value coded per an ISO standard [this document]

Expert Review RRTYPE identifiers are assigned under the DNS RRTYPE Allocation Policy of , an Expert Review process conducted on the basis of completed application templates conforming to the template of . Completed templates for both types defined here were submitted separately to dns-rrtype-applications@ietf.org, and Expert Review completed on 20 August 2026. The registry entries reference this document as an Internet-Draft; IANA is requested to update both references to point to this document upon its publication as an RFC.

This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK] ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. [STANDARDS-TRACK] United Nations Economic Commission for Europe United Nations Economic Commission for Europe as revised United Nations Economic Commission for Europe as revised International Organization for Standardization as amended International Organization for Standardization as amended International Organization for Standardization as amended

Changes from -00 Section 7 updated to record the RRTYPE assignments made by Expert Review on 20 August 2026: UNECE = 69 and ISO = 70. No other technical changes.