Background to NAPTR Resource Records and the ENUMservice Field

This document gives a background to "NAPTR" Resource Records and the "ENUMservice" field and is mainly derived directly from the referenced RFCs, and is contained in Annex A ETSI TS 102 172 "Mininmum Requirements for Interoperability of European ENUM Trials for information.

The ENUM System as defined in Internet Draft <draft-ietf-ENUM-rfc2916bis-03.txt>, which will supersede RFC 2916 , discusses the use of the DNS for identifying available services connected to an E.164 number. Through the transformation of E.164 numbers into DNS names and the use of existing DNS services, especially the NAPTR records as defined in RFC 3403, one can look up what services are available for the related E.164 number.

ENUM is about a specific usage of "NAPTR" Resource Records within the Domain Names System (DNS), as explained within the Dynamic Delegation Discovery System (DDDS). The DDDS is specified in a series of documents (RFC 3401to RFC 3405).

The Dynamic Delegation Discovery System (DDDS) is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached.

An introduction and overview to the DDDS is given in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). In order to fully understand any document in this series it should be noted that all other documents should also be read.

"Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database" (RFC 3403) describes the way in which the Domain Name System (DNS) is used as a data store for the Rules that allow a DDDS Application to function. It does not specify any particular application or usage scenario. The present document also obsoletes RFC 2915. ENUM is a particular "application" and described in RFC 2916bis.

The Naming Authority Pointer (NAPTR) DNS Resource Record (RR) specified in RFC 3403 was originally produced by the IETF URN Working Group as a way to encode rule-sets in DNS so that the delegated sections of a Uniform Resource Identifiers (URI) <RFC 2396> could be decomposed in such a way that they could be changed and re-delegated over time. The result was a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name.

Regular expressions were chosen for their compactness to expressivity ratio allowing for a great deal of information to be encoded in a rather small DNS packet. They are a combination of a POSIX Extended Regular Expression and a replacement string similar to Unix sed-style substitution expression, for the syntax see RFC 3402.

In the case where two "Applications" may use the same database (which is actually the case with DNS and the ENUM and URI Resolution Applications), there is a chance of collision between rules where two NAPTR records appear in the same domain but they apply to more than one Application. Different ways exist to avoid collisions, the way chosen in ENUM is to use different values in the Services field (see below), so a record from another Application will be ignored since it doesn't apply to the Service fields in question.

The packet format of the NAPTR RR is given below. The DNS type code for NAPTR is 35.

The packet format for the NAPTR record is as follows:

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ORDER |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| PREFERENCE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

/ FLAGS /

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

/ SERVICES /

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

/ REGEXP /

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

/ REPLACEMENT /

/ /

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

<character-string> and <domain-name> as used here are defined in RFC 1035.

"ORDER" field

A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed in order to accurately represent the ordered list of Rules. Since no ordered lists are used within the ENUM Field trials, this field is not applicable within the ENUM Trials.

"PREFERENCE" field

Although it is called "preference" in deference to DNS terminology, this field is equivalent to the Priority value in the DDDS Algorithm. It is a 16-bit unsigned integer that specifies the order in which NAPTR records with equal Order values SHOULD be processed, low numbers being processed before high numbers. This field is applicable in the ENUM field trials.

"FLAGS" field

A <character-string> containing flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set A-Z and 0-9. The case of the alphabetic characters is not significant. The field can be empty. It is up to the "Application" specifying how it is using this Database to define the Flags in this field. It must define which ones are terminal and which ones are not. Therefore RFC 2916bis specifies that at this time only one flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI (see ref).

"SERVICES" field

A <character-string> that specifies the Service Parameters applicable to this delegation path. It is up to the "Application" Specification to specify the values found in this field.

Therefore RFC 2916bis defines this field as follows:

Service Parameters for this "Application" (ENUM) take the following form and are found in the Service field of the NAPTR record.

service_field = "E2U" 1*(servicespec)
servicespec = "+" ENUMservice
ENUMservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT)
subtype = 1*32(ALPHA / DIGIT)

In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) followed by 1 or more "ENUMservices" which indicate what class of functionality a given end point offers. Each "ENUMservice" is indicated by an initial '+' character.

An ENUMservice MUST be registered with the IANA via a description in an RFC. "ENUMservices" specifications contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be returned. Note that there is no implicit mapping between the textual string "type" or "subtype" in the grammar for the ENUMservice and URI schemes or protocols. The mapping, if any, has to be made explicit in the present document for the "ENUMservice" itself. A registration of a specific Type also has to specify the Subtypes allowed.

A registered "ENUMservice" must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI which is the outcome of the use of it.

Specifically, a registered ENUMservice MUST specify the URI scheme(s) that may be used for the ENUMservice,

Since there is not a single "ENUMservice" registered with IANA yet, the definition of this field is one of the main purposes of the present document.

"REGEXP" field

A <character-string> containing a substitution expression that is applied to the "original string" held by the client in order to construct the next domain name to lookup. See the DDDS Algorithm specification (RFC 3402) for the syntax of this field. In case of the ENUM Trials, the regexp always produces an URI.

"REPLACEMENT" field

This field is not used within ENUM Trials.

RFC 2916bis defines in addition how to get the "original string" mentioned above and how to access the database (for more information on the terms used see the DDDS RFCs):

· that the Application Unique String (AUS) for ENUM is a fully qualified E.164 number minus any non-digit characters except for the '+' character which appears at the beginning of the number.

· that the First Well Known Rule for ENUM is the identity rule, which gives the original string.

· that the output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in RFC 2396.

· that at present only one DDDS Database is specified for ENUM. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" (RFC 3403) specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain-names.

The output of the First Well Known Rule for the ENUM Application is the E.164 number minus all non-digit characters except for the +. In order to convert this to a unique key in this Database the string is converted into a domain-name according to this algorithm:

1) Remove all characters with the exception of the digits. For example, the First Well Known Rule produced the Key "+4689761234". This step would simply remove the leading "+", producing "4689761234".

2) Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4

3) Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4

4) Append the string ".e164.arpa" to the end. Example: 4.3.2.1.6.7.9.8.6.4.e164.arpa

This domain-name is used to request NAPTR records which may contain the end result or, if the flags field is blank, produces new keys in the form of domain-names from the DNS (the latter variant is currently not user in the ENUM Trials).