The Full Wiki

More info on NAPTR record

NAPTR record: Wikis

Advertisements
  

Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.

Encyclopedia

From Wikipedia, the free encyclopedia

A Name Authority Pointer (NAPTR) is a type of resource record used in the Domain Name System (DNS). DNS is a key part of the Internet's infrastructure. It provides on the one hand a way for users to find information about domain names and on the other a way for domain name managers to publish information. Different DNS records, such as NAPTR records, are used to pass different information. For example, A records are used to pass the IP address for machines associated with the domain name, while MX records are used to notify users where email directed to a domain name should be sent. In the early days each new kind of information would be passed using a new kind of record. NAPTR pointers provide a general, flexible, extensible, and standard mechanism to pass new kinds of information. They were standardized as part of the effort to block out a generalized form of Universal Resource Identifiers, or URI, known as Universal Resource Names, or URN. So in most cases the information retrieved via a NAPTR is a URI or URN, but it can also be another domain name.

The information stored in NAPTR records is actually a simple program which the user must run to get his actual result. These programs consist of sets of regular expression rewrite rules. A good and widely deployed example is routing phone calls over the Internet. Consider a phone number like 1(800)123-4567 located in the US. The URN for that phone number looks like: tel:+1-800-123-4567. The designers of the scheme for handling tel: URN decided to store information for that phone number in DNS at this domain name 7.6.5.4.3.2.1.0.0.8.1.e164.arpa (see footnote). When everything is correctly configured, a request for NAPTR records from that domain will return some which are marked as 'E2U+SIP', and along with some regular expression rewrite patterns if we apply them to that domain name could resolve into yet another URN, such as <sip:customer-service-4567@example.com>, which in turn can be used to make a VOIP phone call.

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. However, RFC 3403 states that "An Application MUST NOT apply a Rule to the output of a previous Rule. All Rewrite Rules for all Applications must ALWAYS apply to the exact same Application Unique String that the algorithm started with". Therefore, one can daisy chain NAPTR records, as long as the input to one rule is not the output of another.

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" flag signifies a terminal rule in ENUM and URI applications, so the output of this rewrite will be the answer we are looking for. See RFC 2915 for a list of allowed flags.

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 (Regular Expression) 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".

Name server support

BIND Native support
djbdns Not natively supported unless patched; can also use TinyDNS generic records
Windows Server 2003 DNS Server Not supported
PowerDNS Native support

References

See also

  • EDNS is generally also used in NAPTR implementations, to support the longer DNS packets that may be required by the use of multiple NAPTR records
  • List of DNS record types
Advertisements

Advertisements






Got something to say? Make a comment.
Your name
Your email address
Message