The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
obsoleted by
- rfc-6116 — The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
- rfc-6117 — IANA Registration of Enumservices: Guide, Template, and IANA Considerations
obsoletes
- rfc-2916 — E.164 number and DNS
Extracted elements (23)
The ENUM algorithm always returns a single rule, not multiple rules. Specific applications may present multiple results via application-specific facilities, but this must not change the operation of the underlying DDDS algorithm.
The service field format was changed from RFC 2916's 'example+E2U' to the new 'E2U+example' format to support multiple Enumservices per NAPTR RR, added subtypes, and general IETF agreement that the main selector (E2U) should appear first.
Some nameserver implementations (e.g., BIND) may insert additional A records into DNS responses for domains found in NAPTR records. DNS servers MAY interpret Flag values to include appropriate additional resource records; clients are encouraged but not required to check for this additional information.
A client implementing ENUM MUST adhere to the Order field in NAPTR records (a request from the E.164 holder), but may treat the Preference field merely as a suggestion for local policy selection.
A registered Enumservice MUST specify the URI scheme(s) that may be used, and any other information needed for URI resolution. The type MUST be unique and MUST NOT start with 'X-' (reserved for experimental use).
An analysis of security issues is required for all registered Enumservices. All known security risks must be identified; stating 'no security issues' must not be confused with 'security issues have not been assessed'.
An Enumservice type MUST be unique and conform to the ABNF in Section 2.4.2. Subtypes MUST be unique within a given type. Neither type nor subtype MUST NOT start with 'X-', which is reserved for experimental private use.
ENUM compliant applications MUST only query DNS for what it believes is an E.164 number. The E2U portion of the service field MUST NOT be used for non-E.164 numbers.
If a client encounters a NAPTR record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields.
If a NAPTR flag is not present (non-terminal rule), clients MUST use the Key produced by the Rewrite Rule as the new Key in the DDDS loop, causing the client to query for new NAPTR records at the resulting domain-name.
Private dialing plans reusing ENUM mechanisms MUST NOT use the suffix 'e164.arpa' to avoid conflict, MUST NOT be called 'ENUM', and the AUS SHOULD be the full number without the leading '+'.
Proposals for Enumservice registrations MUST be published as an RFC on the Standards Track, Experimental RFC, or as a BCP. IESG approval and RFC publication are required for a registered ENUM service.
Software implementing ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses, EDNS0 signaling, and unknown RRs.
The Application Unique String (AUS) for ENUM is a fully qualified E.164 number minus any non-digit characters except for the leading '+' character. For example, '+44-116-496-0348' becomes '+441164960348'.
The First Well Known Rule for ENUM is the identity rule: the output is the same as the input AUS. This works because the E.164 namespace is organized to allow direct mapping from the number to the namespace.
IANA created a registry for Enumservices. New Enumservices are registered upon RFC publication via the IETF process. Registrations include type, subtype(s), URI scheme(s), functional specification, security considerations, and intended usage.
Call routing environments with multiple providers may provide incentives for unauthorized changes to routing or supplier information. Systems must include adequate mechanisms for identification, authentication, and authorization of requested changes.
DNS caching means changes to NAPTR records may take up to the TTL duration to propagate. In environments with dynamic IP addresses (e.g., DHCP), this propagation delay must be carefully managed.
ENUM uses DNS which in its current form is an insecure protocol with no built-in data authenticity mechanism. A deployed ENUM service SHOULD include mechanisms to ameliorate DNS threats such as packet interception, ID guessing, name-based cache poisoning attacks, and denial of service. DNSSEC is recommended once deployed.
Even if DNSSEC is deployed, a service using ENUM for address translation should not blindly trust that a peer is the intended party; services should always authenticate peers as part of setup for the service itself.
Security issues related to URI resolution must be specified in the registration of each Enumservice, as the DDDS mechanism produces URIs whose resolution carries service-specific security implications.
E.164 numbers are converted to DNS domain-name keys by: (1) removing non-digits, (2) inserting dots between each digit, (3) reversing digit order, (4) appending '.e164.arpa'. Example: +442079460148 becomes 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
The NAPTR service field for ENUM follows the form: 'E2U' followed by one or more '+'-prefixed enumservices. Each enumservice has a type (1-32 alphanumeric chars) and optional subtypes separated by ':'. Example: 'E2U+sip' or 'E2U+sip:tel'.