The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
obsoletes
- rfc-3761 — The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
Extracted elements (25)
The E.164 number is reversed digit-by-digit and appended to 'e164.arpa' so that the DNS delegation hierarchy mirrors the ITU E.164 numbering hierarchy (country code at the top), enabling decentralized zone administration at each level of the number plan.
The 'E2U' token is required in NAPTR Services fields to distinguish ENUM rules from other DDDS applications that may also use NAPTR records, preventing collisions between applications sharing the same DNS zone.
The 'X-' Enumservice prefix is reserved for experimental use and cannot be registered, while 'P-' is reserved for private network use and will not be registered, to prevent leakage of private service descriptions into public ENUM infrastructure.
Case sensitivity was not addressed in RFC 3761 and caused interoperability failures at test events. This document mandates case-insensitive processing for Public ENUM clients while allowing case-sensitive processing only in fully controlled Infrastructure ENUM environments.
ENUM clients MUST support current NAPTR syntax (Section 3.4.3) and SHOULD also support the obsolete RFC 2916 syntax, as deployed zones may still contain old-format NAPTRs. ENUM clients MUST also handle non-E2U DDDS application identifiers without failure.
Some deployed ENUM clients confuse ORDER and PREFERENCE/PRIORITY fields (using the latter as major sort term) or pre-discard NAPTRs not at the lowest ORDER value. Provisioning systems SHOULD use ORDER value '100' as default and not rely on clients strictly following ordering rules.
A non-terminal NAPTR MUST include its target domain in the (non-empty) Replacement field, and the Regexp field MUST be empty in a non-terminal NAPTR intended to be encountered during an ENUM query.
An ENUM-compliant application MUST only pass numbers it believes are E.164 numbers to the ENUM client query process; it MUST NOT pass dialed digit strings.
Domain names used for ENUM-like techniques applied to private dialing plans or other digit strings MUST NOT use 'e164.arpa' as the domain apex, and the schemes MUST NOT be described as 'ENUM'.
ENUM clients MUST be prepared to encounter referential loops in sequences of non-terminal NAPTRs and MUST be able to detect and recover from such loops without failure. Clients MAY treat a chain of more than 5 non-terminal NAPTRs as an indication of a loop.
ENUM clients MUST sort NAPTR RRSet records by ORDER (major, ascending) and PREFERENCE/PRIORITY (minor, ascending). A record with a worse ORDER value MUST NOT be discarded before consideration unless a record has already been accepted.
ENUM clients MUST use case-insensitive processing when exposed to NAPTR records that may hold field content of different capitalization, as in Public ENUM scenarios. A client MAY use case-sensitive processing only if it is known to operate in a fully controlled environment.
ENUM zones MUST NOT be provisioned with NAPTRs using the obsolete syntax of RFC 2916; NAPTRs MUST use the Services field syntax defined in Section 3.4.3 of this document.
If the literal '+' character appears in the ERE sub-field of an ENUM NAPTR, it MUST be escaped as '\+'. The Regexp delimiter character, if it appears in the static text of the Repl sub-field, MUST also be escaped.
NAPTRs with an Enumservice type starting with 'P-' MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR RRSets from entities outside the intended private network context. ENUM clients MUST discard any such NAPTR unless sure they are on the intended private network.
Software implementing ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses, EDNS0 signaling, and unknown resource records.
Compound NAPTRs may hold more than one Enumservice in a single record (e.g., 'E2U+voice:tel+sms:tel'), sharing the same Regexp field and generating the same URI. These are treated as logically separate NAPTRs with left-to-right priority ordering.
The Application Unique String (AUS) for ENUM is a fully qualified E.164 number minus any non-digit characters except for the leading '+' character. The '+' is retained to distinguish E.164 numbers from other telephone number formats.
The First Well Known Rule converts an E.164 AUS into a DNS FQDN by: (1) removing all non-digit characters including '+', (2) reversing the digit order, (3) inserting dots between each digit, and (4) appending '.e164.arpa.' to produce the query domain name.
The NAPTR Services field for ENUM uses the ABNF form: 'E2U' followed by one or more Enumservices each prefixed with '+'. Each Enumservice has a type (1-32 alphanumeric or '-' characters) and zero or more subtypes separated by ':'.
The 'U' flag in a NAPTR record signals that the DDDS algorithm has finished and the output is a URI. If a client encounters an unknown flag it MUST ignore the record and move to the next rule.
The 'e164.arpa' domain is delegated to provide DNS infrastructure for E.164 number data. Subdomain delegations must be consistent with ITU E.164 hierarchy. The IAB coordinates with ITU TSB on technical contact changes. Enumservice registrations are governed by RFC 6117.
DNS caching and unsynchronized TTLs across the chain of records (NAPTR, SRV, A, DHCP) used to resolve a communication target can cause transient states where stale or misdirected contact information is used. Provisioning systems SHOULD minimize record changes and users SHOULD detect unintended session attempts.
ENUM relies on DNS, which is insecure without DNSSEC. Deployed ENUM services SHOULD include DNSSEC to mitigate data authenticity threats, though DNSSEC does not protect against Denial-of-Service attacks or guarantee that a connected endpoint is the intended peer.
In environments with multiple call routing providers, systems allowing users or agents to change routing or supplier information SHOULD implement strong identification, authentication, and authorization to prevent unauthorized changes.