NAPTR records are among the least familiar DNS record types, and for good reason: most people never touch them. But if you run a SIP trunk, configure a VoIP gateway, or work anywhere near telephone-number-to-URI mapping, NAPTR is the record that makes service discovery work. It is a rewriting rule stored in DNS, designed to turn one string into another and point you at the next lookup. This guide explains what NAPTR records do, how each of their fields works, and where they show up in SIP, VoIP, and ENUM.
What a NAPTR record is for
NAPTR stands for Naming Authority Pointer, and it is defined as part of the Dynamic Delegation Discovery System (DDDS) in RFC 3403. The core idea is that a client has an input string, applies a set of ordered rules stored as NAPTR records, and ends up either with a final result or with a pointer to the next DNS lookup to perform. It is used when a simple A or SRV lookup is not expressive enough, typically because you need to choose among several protocols or transports, or rewrite an identifier like a phone number into a service address.
Rather than hardcoding "connect to this host on this port," NAPTR lets a domain publish a prioritized menu of options and the transformations needed to reach each one. The client walks that menu in order.
The six fields of a NAPTR record
A NAPTR record has six fields after the standard name, TTL, class, and type. Understanding each is the whole game.
| Field | Type | Purpose |
|---|---|---|
| Order | 16-bit integer (0 to 65535) | Processing sequence; lowest order is evaluated first |
| Preference | 16-bit integer (0 to 65535) | Tiebreaker among records with equal order; lower first |
| Flags | String, single chars A-Z and 0-9 | Controls what happens next; common values A, S, U, P |
| Service | String | The service and protocol this rule applies to |
| Regexp | String | A substitution rule that rewrites the input into an output |
| Replacement | Domain name | The next name to query, used when regexp is empty |
Order and preference
Order is the primary sort key. A client must process NAPTR records from lowest order to highest to honor the intended rule sequence. Preference breaks ties between records that share the same order, again lowest first. Together they let a domain express "try this first, then that," for example preferring TLS transport over UDP.
Flags
Flags tell the client what kind of step this is. The values defined for the common applications are the letters A, P, S, and U, plus the empty string.
- S: the replacement points to an SRV record; look that up next.
- A: the replacement points to an address record (A or AAAA); look that up next.
- U: terminal. The regexp produces a complete URI and there is no further DNS lookup.
- P: protocol-specific. Processing continues in a way defined by the application, not by the generic DDDS algorithm.
- Empty: non-terminal; the replacement is another NAPTR to evaluate.
Service, regexp, and replacement
The service field names the protocol combination this rule covers, such as SIP+D2T for SIP over TCP or SIPS+D2T for SIPS over TLS. The regexp and replacement fields are mutually exclusive in practice: a rule either rewrites the input with a regular expression (regexp populated, replacement set to a single dot) or it simply forwards to another name (regexp empty, replacement is the next FQDN). A terminal U-flag rule uses the regexp to build the final URI.
NAPTR in SIP and VoIP
SIP uses a well-known pattern often called NAPTR plus SRV plus A. A client that knows only a domain discovers how to reach its SIP service in three steps. First it queries NAPTR to learn which transports are offered and in what order. Each NAPTR with the S flag points at an SRV record. The client then resolves that SRV to find the host and port, and finally resolves the host's A or AAAA record to get an address.
$ dig NAPTR example.com +short
10 50 "S" "SIPS+D2T" "" _sips._tcp.example.com.
20 50 "S" "SIP+D2T" "" _sip._tcp.example.com.
30 50 "S" "SIP+D2U" "" _sip._udp.example.com.Here the lowest order, 10, offers SIPS over TLS and is tried first; if that path is unavailable the client falls back to plain SIP over TCP, then UDP. Each S-flag record forwards to an SRV name, which the client resolves next.
$ dig SRV _sips._tcp.example.com +short
10 10 5061 sip1.example.com.
$ dig A sip1.example.com +short
203.0.113.60NAPTR in ENUM
ENUM maps E.164 telephone numbers to internet services using NAPTR records in the e164.arpa zone. The phone number is reversed digit by digit, dotted, and suffixed with e164.arpa to form the query name. NAPTR records at that name then rewrite the number into service URIs such as a SIP address or a mailto.
; The number +1 555 123 4567 becomes:
; 7.6.5.4.3.2.1.5.5.5.1.e164.arpa
$ dig NAPTR 7.6.5.4.3.2.1.5.5.5.1.e164.arpa +short
100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
102 10 "U" "E2U+email" "!^.*$!mailto:info@example.com!" .These are terminal U-flag records. The regexp !^.*$!sip:info@example.com! matches the entire input and replaces it with a SIP URI, giving the caller a direct address to dial over IP. The replacement field is a bare dot because the regexp, not a replacement name, produces the result.
Reading a NAPTR rule in practice
- Sort the records by order, then by preference, and process in that sequence.
- Read the flag to know the next move: S means follow to SRV, A means follow to an address, U means you already have your URI.
- If the flag is S or A, the replacement names the next record to look up and the regexp is empty.
- If the flag is U, apply the regexp to your input string to build the final URI.
Verify your NAPTR records resolve correctly
Because NAPTR drives multi-step service discovery, one malformed record can silently route calls to the wrong transport or nowhere at all. After publishing, confirm the records are live and consistent by running the name through the Valla DNS propagation checker, then cross-check the SRV and address records they point to. Our guides on SRV records and reading a DNS trace pair naturally with this one, since a NAPTR lookup is almost always the first link in a longer chain.