techblog 

NAPTR stands for Naming Authority Pointer. This is a form of DNS record which allows for one or more services to be associated with a unique string, and for the string to be re-written using regular expressions. The main usage of NAPTR records is within ENUM, the application which maps phone numbers onto other, IP-based services in VoIP. However, NAPTR is part of a more abstract system: DDDS, the Dynamic Delegation Discovery System. The DDDS is discussed below with reference to ENUM as an example DDDS application.

DDDS

The DDDS “is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems” [RFC 3401]. In DDDS, a unique string is mapped by an application onto a set of services using a rule database, which consists of a set of rewrite rules, applied recursively until a terminal condition is reached. The terminal condition must make sense to the application, whilst the intermediate output of rewrite rules must be keys into the rule database.

In ENUM, there is only ever one rewrite rule applied, the NAPTR record. The output of this rule is terminal, and is a URI pointing to a VoIP service.

DDDS Applications are specified in terms of:

• The Application Unique String (AUS). This is the thing that the rules act on. In ENUM this is a phone number with no spaces and no punctuation, save for a ‘+’ in front of the country code. The AUS for Nominet’s phone number is therefore +441865332211.
• The First Well Known Rule. This rule says where the process starts. In ENUM the database is DNS, specifically the e164.arpa tree. This is organised in the exactly the same way as the E164 numberspace. The transformation is therefore the identity function. No transformation occurs.
• A list of valid databases, in this case DNS. To allow for DNS lookups the resolver called by the application must translate from a phone number into a leaf in the e164.arpa tree. Nominet’s number translates into 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa.
• The final expected output. ENUM is an application which turns phone numbers into VoIP services, such as email, so the expected output is a valid URI pointing to a service such as SIP or email.
• The algorithm used in DDDS, and the specific requirements for applications and databases are defined in RFC 3402.

Format of NAPTR records

The NAPTR record is defined in RFC 3403. It was designed specifically to represent rewrite rules in DNS, so allowing DNS to be a valid DDDS database.

NAPTR records have six fields. The first two, order and preference are used to distinguish between several possible rewrite rules through defined priority. They are specifically NOT for load balancing. The important difference between the two fields is that, once a matching record is found, “the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences”. The preference field is a way of expressing the hierarchy of quality of services that are available

Another way of looking at this is that the order specifies how the holder of the delegation wishes the rules to be processed, whereas the preference is may be over-ridden by the client depending on which service it wishes to use. Interpreting it in this way, the order
field is analogous to the MX preference value.

The third field is a flag. In the DDDS algorithm this flag is intended to signal where in the process the rewrite rules have reached. In ENUM NAPTR records it is always “u” to indicate that the output is terminal and results in a URI. That is, processing finishes with this rule.

The fourth field is service. This is a character string that is defined in the application specification. For ENUM this always start “E2U+”, though case is insignificant. This is immediately followed by the type of service. SIP is represented as “e2u+sip”, therefore. Some service types may include further subtypes, such as “e2u+sms:tel”, for text messaging and “e2u+sms:mailto”, for SMS delivery over SMTP. A full list of ENUM services can be found at http://www.iana.org/assignments/enum-services.

Next comes regular expression. This is a Perl-like regex which rewrites all or part of the AUS. Note, it is not the key that is being rewritten. In ENUM terms this means that the phone number is being translated, not the e164.arpa domain name.

Finally comes the replacement field. This is a FQDN which is the next step in the DDDS chain, ie. the next key to look up. As NUM NAPTR records are always terminal this is always a single dot.

ENUM Example

An example NAPTR record set may clarify things. This is lifted from RFC 3761. As it states there, the services listed do not necessarily tally with real enumservices, but the example is valid.

$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.        NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
                                                  NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
                                                  NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .

This record set maps the phone number +441632960083 onto three possible identically ordered URIs, with a preference for SIP, then H323, and finally email. In each case, the regular expression matches the full AUS (^.$), and replaces it with a URI (e.g., sip:info@example.com). As this is a terminal record, this URI is returned to the client.Though most NAPTR records replace the full AUS, it is possible for the regular expression to back-reference part of the AUS, to grab an extension number, say:

$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. *   NAPTR 10 100 "u" "E2U+sip""!^+441632960(.*)$!sip:1@example.com!" .

Once the client has the URI it must be resolved using DNS, but this is no longer part of the DDDS algorithm..

Other Applications using NAPTR records

But then again, it could be. RFC 3404 describes “DDDS Based URI Resolution”.

It is a long stated goal to use persistent, location-independent Uniform Resource Names (URNs) in preference to more brittle URIs. This would allow publication of persistent pointers to resources that are not dependent on service configuration. The Knoxville framework, referenced in RFC 3404, adopts the approach of separating name assignment from resolution. DNS is an established and widely used resolution framework, but it is not suitable for URNs, for reasons of scale amongst other things. DDDS is recommended as a mechanism which can use DNS to locate URN “resolvers” through URI rewriting.

The URI and URN resolution applications are technically identical, but operate independently. Both use DNS as the valid database, and each has either the URI or URN as its AUS. The First Well Known Rule extracts the key from the AUS. In the URI case this is the URI scheme, for URNs it is the Namespace Identifier. To use DNS with these keys it is necessary to request NAPTR records in the ‘.uri.arpa.’ and ‘.urn.arpa.’ trees.The database contains NAPTR records of the format described above. Four flags are defined, of which three describe terminal conditions:

• “S” means the out put of the rule is a domain-name for which SRV records exist.
• “A” means the out put is a domain-name that can be used to find A and AAAA records.
• “U”, as above, yields a URI.
• “P” means that the rest of the process is application-specific, and is out of the scope of DDDS.
• An empty flag indicates that a further DDDS loop is required.

The service field may contain protocol information. It will probably contain some service information allowing URIs to be resolved to one or more URIs, resources or descriptions of resources.

The RFC contains complex and detailed NAPTR examples for URN and URI resolution. These examples are very detailed, and repetition here would be mere plagiarism. What they do show is the versatility of DDDS and the NAPTR record for resource discovery.