NAPTR records are most commonly used for applications in Internet telephony, for example, in the mapping of servers and user addresses in the Session Initiation Protocol (SIP). The combination of NAPTR records with Service Records (SRV) allows the chaining of multiple records to form complex rewrite rules which produce new domain labels or uniform resource identifiers (URIs).
The DNS type code for the NAPTR record is 35.
Uniform Resource Names (URNs) are a subset of Uniform Resource Identifiers (URIs) used for abstract identifiers, such as a person's name or their telephone number. For URNs to be meaningful, they must be mapped to a concrete resource of some sort. Uniform Resource Locators (URLs) are often used to describe such resources, such as a computer hostname, or a local file.
The NAPTR record aids in the standardization of URNs. NAPTR records map between sets of URNs, URLs and plain domain names and suggest to clients the protocols available for communication with the mapped resource. Each NAPTR record contains a service name, a set of flags, a regular expression rule, an order value, a preference and a replacement pattern. Multiple records can be chained together in a cascade to rewrite URIs in deterministic ways. These cascading rules have been standardized in RFC2915 and RFC3403.
A common use for NAPTR records is in Session Initiation Protocol, where it is used to route telephony sessions over the IP networks. For example, the SIP URN for the US telephone number 1-800-555-1234 might be tel:+1-800-555-1234 and its domain name 18.104.22.168.22.214.171.124.0.8.1.e164.arpa. A SIP client querying that name might receive:
$ORIGIN 126.96.36.199.188.8.131.52.0.8.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:email@example.com!" . IN NAPTR 102 10 "U" "E2U+email" "!^.*$!mailto:firstname.lastname@example.org!" .
The first record has an order value of 100, which is lower than 102 and therefore has precedence. Its preference of 10 is unimportant as there are no other rules with order 100. The service name E2U+sip is an ENUM string indicating that the record can be used in telephone number-to-SIP-URI queries. The client applies the regular expression !^.*$!sip:email@example.com!, which replaces its entire URN tel:+1-800-555-1234 with sip:firstname.lastname@example.org. The flag U indicates that the replacement string is a SIP URN, and that no further rules should be applied.
To resolve SIP URN, the client performs a second NAPTR lookup—on example.com, yielding:
$ORIGIN example.com. IN NAPTR 100 10 "S" "SIP+D2U" "!^.*$!sip:email@example.com!" _sip._udp.example.com. IN NAPTR 102 10 "S" "SIP+D2T" "!^.*$!sip:firstname.lastname@example.org!" _sip._tcp.example.com.
As in the first example, the client picks the first record because it has the lowest order value. The regular expression rule replaces the query URN, this time with the domain name _sip._udp.example.com. The flag S indicates that the resulting domain name points to a SRV record. The client thus finishes with _sip._udp.example.com, for which it can then fetch a SRV record to initiate a telephony call.
|Daniel J. Bernstein||djbdns||No (requires patch)|
|Microsoft||Windows Server 2003 DNS Server||No|
|Microsoft||Windows Server 2008 R2 DNS Server||Yes|
|Secure64||Secure64 DNS Authority DNS Server||Yes|
|Sam Trenholme||MaraDNS||version 1.4 on|
NAPTR implementations generally also implement EDNS as responses returning multiple NAPTR records are usually larger than the normal 512 byte packet size limit and would otherwise require a less efficient fallback to TCP rather than UDP.
- Mealling, M; Daniel, R (2000), RFC2915: The Naming Authority Pointer (NAPTR) DNS Resource Record, IETF Network Working Group
- Mealling, M (2002), RFC3403: Dynamic Delegation Discovery System (DDDS), Part Three: The Domain Name System (DNS) Database, IETF Network Working Group
- Sollins, K (1998), RFC2276: Architectural Principles of Uniform Resource Name Resolution, IETF Network Working Group
- van der Berg, Rudolf (2010-01-13), ENUM: Dragging telephone numbers into the Internet Age, Ars Technica
- "Updating MaraDNS". Retrieved 2009-01-17.