rfc-2916

E.164 number and DNS

P. Faltstrom
date2000-09 streamIETF arearai wgenum statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc2916 doi10.17487/RFC2916 errataview
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. [STANDARDS-TRACK]

obsoleted by

Extracted elements (16)

design-rationale §2.1

The '+' is retained through step 2 of the E.164-to-DNS conversion to flag that the number being processed is an E.164 number. Future work may be needed to handle other numbering plans (such as closed ones) which might use a similar mechanism.

dns

design-rationale §1

The system uses existing DNS infrastructure (NS record delegation and NAPTR records) to enable decentralized lookup with distributed management at different levels, rather than a centralized database. This allows E.164 number holders to manage their own DNS zones.

dns

interoperability-note §3.2.2

When the NAPTR rewrite produces a 'tel' URI, the resolution process is restarted with the new E.164 number. The client is responsible for loop detection in this case.

dns

normative-requirement §3.1 MUST

When multiple NAPTR records are returned in response to a single query, records MUST be processed in the order specified by the order field.

dns

normative-requirement §3.1 SHOULD

When multiple NAPTR records share the same order value, records SHOULD be processed according to the preference field.

dns

protocol-element §2

E.164 numbers are stored in DNS under the 'e164.arpa' domain, divided into subdomains to facilitate distributed operations. Holders of E.164 numbers must contact the appropriate zone administrator to be listed.

dns

protocol-element §3

NAPTR resource records are used to identify available services for a specific E.164 number in DNS. The input to the NAPTR algorithm is the E.164 number after step 2 processing (leading '+' and digits only); the output is an absolute URI per RFC 2396.

dns

protocol-element §2

The algorithm to convert an E.164 number to a DNS name has six steps: write in full form with country code, remove non-digit characters except leading '+', remove '+', insert dots between digits, reverse digit order, and append '.e164.arpa'. For example, +46-8-9761234 becomes 4.3.2.1.6.7.9.8.6.4.e164.arpa.

dns

protocol-element §3.1.2

The E2U (E.164 to URI) service is defined for NAPTR use in this system. It takes one operand (an E.164 number in the form from step 2 of the conversion algorithm) and outputs one or more URIs. Error conditions include: number not in numbering plan, number in plan but no URIs exist, and service unavailable.

dns

protocol-element §3.1

The NAPTR record key fields are: order (sequence for processing multiple records), preference (tie-break within same order), service (resolution protocol and services), flags (modifiers for next DNS lookup), regexp (rewrite rule core), and replacement (alternative rewrite field). Clients apply all substitutions; DNS servers do not.

dns

protocol-element §3.2

URIs are stored in the NAPTR regexp field. The service field uses compound names like 'sip+E2U', 'mailto+E2U', 'tel+E2U', or 'ldap+E2U' to identify the protocol and E2U service. The 'u' flag in the flags field indicates the result is a URI.

dns, sip

registry §4

This memo requests that IANA delegate the E164.ARPA domain following instructions from the IAB. Names within the zone are to be delegated per ITU Recommendation E.164, with hierarchical codes assigned accordingly. Delegations in e164.arpa (not in sub-delegated domains) require Expert Review, with a designated expert appointed by the IESG.

dns, registry

security-consideration §5

Because this system is built on DNS, information retrieved is only as secure as DNS itself. Use of DNSSEC for securing and verifying zones is recommended to improve security.

dns, security

security-consideration §5

DNS caching means propagation time for a change can equal the TTL of NAPTR records. Use in environments with dynamic IP address assignment (e.g., DHCP) must be done carefully to avoid stale mappings.

dns, security

security-consideration §5

In environments with multiple call routing providers, systems that allow users or their agents to change routing or supplier information may provide incentives for unauthorized changes or denial of legitimate change requests. Adequate mechanisms for identification, authentication, and authorization of change requesters are required.

dns, security

security-consideration §3.1.2

Malicious redirection is a fundamental danger: a malicious entry in a resolver's database can cause clients to resolve an E.164 number to a wrong URI, potentially retrieving fraudulent or damaging content. Denial of service is also possible by removing the URI to which the E.164 maps.

dns, security