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" "E2U+sip" "!^.*$!sip:information@pbx.example.com!i" .
IN NAPTR 102 10 "u" "E2U+email" "!^.*$!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 "E2U+sip",
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 "s/^.*$/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". |
