Call me...on DNS

DNS has proven incredibly versatile and scalable in resolving email, web, and application services names to IP addresses across the global Internet for over three decades. And its versatility seems to have no limits as DNS can even be used to map telephone numbers into IP addresses too. The means to perform this mapping function is useful for voice applications, not to mention other generic applications requiring resolution with one or more layers of indirection. The ENUM (E.164 telephone number mapping) service has been defined to support telephone number resolution. ENUM supports the mapping of telephone numbers, in ITU E.164 format, into uniform resource identifiers (URIs). A URI is an Internet identifier consisting of a uniform resource name (URN) and a uniform resource locator (URL). A simple example: for URL http://www.ipamworldwide.com with URN file.txt, the corresponding URI would be http://www.ipamworldwide.com/file.txt. 

The mapping of E.164 numbers (or other arbitrary domain names for that matter) to URIs is performed primarily using the Naming Authority Pointer (NAPTR) resource record type in DNS. NAPTR records were initially defined to provide a means to iteratively resolve an arbitrary string into a URI for the Dynamic Delegation Discovery System (DDDS). Some background on DDDS is provided in RFC 3402, but it initially stemmed from the desire to define a resolution process that could enter with a resource name (e.g., a particular application or piece of data) which in itself, contains no network location information, and resolve it to a destination resource identifier by applying a series of iterative rules from a database, DNS in this case. This separation of the specification of the resource name from the process to locate or resolve it facilitates the making of changes and re-delegations of resources without impacting the end user application’s naming convention.

The NAPTR record enables the specification of such rules within DNS, often using multiple record types including A, AAAA, SRV and even iterative NAPTR records to fully complete the resolution process. Each NAPTR record translates a given entry string, i.e., a valid DNS domain name, into another name or regular expression that can be applied to the input string to derive the next name to lookup. This process iterates until a terminal rule is reached and the final result is returned to the requesting application.

The record data portion of the NAPTR record type contains Order and Preference fields to enable prioritization of multiple records for the same name much like SRV records, a Flags field to denote the resource record type to lookup next, a Services field to indicate the translation type, e.g., URI to URL, ENUM service to URI, etc. as well as Regular Expression and Replacement fields. The Regular Expression field enables entry of a sed-style regular expression for evaluation to derive the next lookup name and Replacement denotes the next lookup name explicitly.

For example, when used to lookup an E.164 telephone number the query name comprises a destination telephone number (with digits reversed much like IPv4 addresses in an in-addr.arpa domain name and suffixed with e164.arpa). The Services field would be "E2U" to denote E.164 translation and the regular expression or replacement would resolve a destination, e.g., a Session Initiation Protocol (SIP) server, mailto URL, or other URI-formatted destination. The resolver would then perform a lookup of the resolved destination name for the type defined in the NAPTR Flags field (typically SRV, A or AAAA) to ultimately complete the resolution process. 

The 3G partnership program, which is a standards body for advanced mobile systems, in conjunction with the European Telecommunications Standards Institute (ETSI) defined the use of NAPTR records for mobile services resource location using DNS in its ETSI TS 129 303 / 3GPP TS 29.303 document: Universal Mobile Telecommunications System (UMTS); LTE; Domain Name System Procedures; Stage 3. This standard stipulates use of "Straightforward NAPTR" or S-NAPTR as defined in RFC 3958, which limits the lookup types to SRV, A, or AAAA types and ignores regular expression processing. For 3GPP applications, e.g. 5G, lookups are performed for particular node names of given types not E.164 telephone numbers, though this merely elucidates the versatility of the NAPTR resource record type. 

Management of a multitude of domains, zones, and node names, not to mention direct and indirect resolution methods via various record types could be overwhelming especially given the scalability requirements of most service provider networks. Use of a highly scalable, available, and flexible IP address management (IPAM) system such as IPControl from Diamond IP by BT can vastly simplify administration of these multiple dimensions of complexity with inherent automation to facilitate provisioning accuracy with scale. IPControl helps the largest service providers on Earth manage their IP space and DNS configurations. Please contact me to learn more.