NAPTR

From Wikipedia, the free encyclopedia

NAPTR stands for Naming Authority Pointer and is a newer type of DNS record that supports regular expression based rewriting. Several NAPTR records can be chained together creating fairly sophisticated URI rewriting rules. A record can go through any number of rewrites before reaching a terminal condition.

For example, after translating the phone number +1-770-555-1212 into the URI 2.1.2.1.5.5.5.0.7.7.1.e164.arpa as described by E.164, DDDS is used to transform it using rewrite rules gathered from NAPTR records. The BIND configuration for the records returned from a query for 2.1.2.1.5.5.5.0.7.7.1.e164.arpa might look like:

$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
 IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@pbx.example.com!i" .
 IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@example.com!i"  .

Of these two records, the first has an order value of 100 which is lower than 102 so it is picked first. The preference of 10 is unimportant as no other rules have an order of 100. The "u" signifies a terminal rule in ENUM and URI applications, so the output of this rewrite will be the answer we are looking for. If we support the service designated with the key "sip+E2U", we won't go on to investigate other rules with higher order values. The rewrite regular expression "!^.*$!sip:information@pbx.example.com!i" is evaluated transforming our original request of 2.1.2.1.5.5.5.0.7.7.1.e164.arpa into sip:information@pbx.example.com. In the regular expression, the exclamation mark '!' will be our delimiter (we avoid the use of '/' and '\' because they may be interpreted as escape sequences somewhere else). The "^.*$" in the RE says "starting at the beginning, including any characters and ending at the end" (in other words, everything) is changed to "sip:information@pbx.example.com" and 'i' ignores case. (Observant readers will notice that the 'i' doesn't matter, given the use of ".*") For those familiar with Perl REs, the equivalent RE could be written as "/^.*$/sip:information@pbx.example.com/i". So the resulting URI "sip:information@pbx.example.com" will be used. If we didn't support SIP, we would effectively fall back to the rule resulting in "mailto:information@example.com".

[edit] References

RFC 2915 - was previously the specification for NAPTR (superseded by RFC 3403 below)
RFC 3401 - DDDS (Dynamic Delegation Discovery System) - uses NAPTR records
RFC 3403 - DDDS Part 3 (DNS) now specifies and describes NAPTR records
Additional background on NAPTR in the context of ENUM can be found at the NIC.at site http://enum.nic.at/documents/Diverse/Background_to_NAPTR.html