NAPTR Lookup

A NAPTR record (Naming Authority Pointer, DNS type 35) holds a rewrite rule instead of an address. It tells a client which services a domain offers, such as SIP over TLS, and which name to look up next, usually an SRV record. NAPTR is defined in RFC 3403 and is used mainly for SIP and ENUM.

An A record tells a client where a host is. A NAPTR record tells the client what to look up next to reach a service. NAPTR was introduced in RFC 2915 and is now specified by RFC 3403 as the DNS binding of the Dynamic Delegation Discovery System (DDDS). A NAPTR record has six fields in a fixed order: order, preference, flags, service, regexp and replacement. A client collects every NAPTR record at a name, sorts them by order and then by preference, and applies the first rule whose service field it supports. The flags field decides what happens next: another NAPTR lookup, an SRV lookup, an address lookup, or a finished URI.

Two applications account for almost all NAPTR records in the public DNS. The first is SIP server location (RFC 3263), where a VoIP client uses NAPTR to discover which transports a domain supports before it queries SRV. The second is ENUM (RFC 6116), where a telephone number is turned into a domain name under e164.arpa and NAPTR records there map it to SIP, email or web URIs.

Every NAPTR record carries the same six fields. Here is a real SIP record decoded field by field:

example.com.  3600  IN  NAPTR  10 50 "S" "SIP+D2T" "" _sip._tcp.example.com.
                              |  |   |       |      |            |
                            order |  flags  service regexp    replacement
                              preference

The regexp and replacement fields are mutually exclusive. A record uses the replacement field when the next name is a fixed string, and the regexp field when the next name has to be derived from the input. ENUM records rewrite a phone number, so they always use regexp and set replacement to a single dot.

The regexp field has the form !pattern!replacement!, a POSIX extended regular expression substitution with a delimiter character (usually an exclamation mark) at the start, middle and end. Backreferences \1 through \9 carry captured groups from the pattern into the output.

NAPTR record example

sip2sip.info, a public SIP service, publishes three NAPTR records. This is what our NAPTR lookup returns for it, followed by the SRV records the two TCP rules point at:

sip2sip.info.  IN NAPTR  5 100 "s" "SIPS+D2T" "" _sips._tcp.sip2sip.info.
sip2sip.info.  IN NAPTR 10 100 "s" "SIP+D2T"  "" _sip._tcp.sip2sip.info.
sip2sip.info.  IN NAPTR 20 100 "s" "SIP+D2U"  "" _sip._udp.sip2sip.info.

_sips._tcp.sip2sip.info.  IN SRV 100 100 5061 proxy.sipthor.net.
_sip._tcp.sip2sip.info.   IN SRV 100 100 5060 proxy.sipthor.net.

Order 5 is the lowest, so a client that supports SIP over TLS takes the SIPS+D2T rule first. Its flag is s, so the replacement _sips._tcp.sip2sip.info is an SRV name, and that SRV record gives the host proxy.sipthor.net and port 5061. A client without TLS support skips to order 10 and ends up at the same host on port 5060 over plain TCP. The preference is 100 on all three records, which does nothing here because no two records share an order value. The regexp is empty in each record because the replacement field names the next lookup.

The flags field is a quoted, case-insensitive string that tells the client what kind of result the rule produces. A terminal flag stops the DDDS rewrite loop, and the client uses the result as it stands. An empty flags string leaves the rule non-terminal, so the loop runs again. Four flags are defined for NAPTR in DNS.

On the public internet you will usually only meet two of these. SIP domains publish S records that point at SRV names, and ENUM zones publish U records that produce a finished sip: or mailto: URI. The A flag skips the SRV step, so the client loses port discovery with it. The P flag hands control to an application-specific algorithm that DNS itself does not define.

RFC 3263 defines how a SIP client locates a server for a domain, and it is the clearest worked example of the chain. The client does not know in advance whether the domain wants UDP, TCP or TLS, so it asks the domain. Take a domain that publishes both TCP and UDP:

; 1. NAPTR at the domain: which transports does it support?
example.com.            IN NAPTR 10 50 "S" "SIP+D2T" "" _sip._tcp.example.com.
example.com.            IN NAPTR 20 50 "S" "SIP+D2U" "" _sip._udp.example.com.

; 2. Order 10 wins, and the "S" flag says look up SRV at the replacement
_sip._tcp.example.com.  IN SRV   10 60 5060 sip1.example.com.
_sip._tcp.example.com.  IN SRV   10 40 5060 sip2.example.com.

; 3. SRV gives host + port; resolve the target to an address
sip1.example.com.       IN A     198.51.100.10
sip1.example.com.       IN AAAA  2001:db8::10

; 4. Result: connect to 198.51.100.10:5060 over TCP

Three DNS round trips produce one connectable endpoint. Order 10 is processed before order 20, so the domain has declared TCP preferable to UDP. Within _sip._tcp.example.com both SRV records share priority 10, so the weights split the traffic 60/40 between sip1 and sip2.

If a domain publishes no NAPTR records, RFC 3263 tells the client to query SRV directly for each transport it supports, in its own order of preference, using the _sips._tcp, _sip._tcp and _sip._udp names. If there are no SRV records either, it falls back to an A/AAAA lookup on the domain itself and uses the default port, 5060 for SIP and 5061 for SIPS.

DNSX walks this whole chain in one request. The NAPTR lookup resolves each rule to its SRV records and each SRV target to its A and AAAA addresses, and it annotates every resolved address with geolocation and ASN, so you can see which network the chain ends on and not just that it resolves. For sip2sip.info the chain is NAPTR order 5 (SIPS+D2T) to _sips._tcp.sip2sip.info to proxy.sipthor.net on port 5061, with the plain TCP rule at order 10 landing on the same host on port 5060.

ENUM (E.164 Number Mapping, RFC 6116) uses DNS to translate a telephone number into a set of URIs. The transformation is mechanical: take the number in full E.164 form, drop every character that is not a digit, reverse the digit order, put a dot between each digit, and append e164.arpa.

+1 202 555 0100                     ; the E.164 number
12025550100                         ; digits only
00105552021                         ; digits reversed
0.0.1.0.5.5.5.2.0.2.1.e164.arpa     ; dot-separated, under e164.arpa

$ORIGIN 0.0.1.0.5.5.5.2.0.2.1.e164.arpa.
  IN NAPTR 100 10 "u" "E2U+sip"   "!^.*$!sip:user@example.com!"    .
  IN NAPTR 102 10 "u" "E2U+email" "!^.*$!mailto:user@example.com!" .

Three things mark these out as ENUM records. The flag is u, because the result is a finished URI and no further DNS lookup happens. The service field starts with E2U, short for E.164 to URI, followed by the scheme: E2U+sip, E2U+email, E2U+web or E2U+pstn. And the replacement field is a single dot, because the regexp field is doing the work.

The regexp !^.*$!sip:user@example.com! matches the whole input and replaces it with a fixed SIP address. More useful zones use backreferences. The regexp !^\+1(.*)$!sip:\1@pbx.example.com! keeps the national part of the number and routes it to a PBX. The order field lets a subscriber express routing preference across schemes: try SIP at order 100, fall back to email at order 102.

The UK delegated its prefix, and Nominet, the .uk registry, publishes ENUM records for its own switchboard number, +44 1865 332244. Each step of the reversal is shown below. The digits of 441865332244 read backwards are 4, 4, 2, 2, 3, 3, 5, 6, 8, 1, 4, 4, and that reversed string with a dot between each digit is the ENUM name. The last two labels before e164.arpa are the country code 44, which is why a country can delegate its whole numbering plan as one DNS zone.

+44 1865 332244                       ; the E.164 number
441865332244                          ; digits only
442233568144                          ; digits reversed
4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa     ; dot-separated, under e164.arpa

$ dig NAPTR 4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa +short
100 10 "u" "E2U+sip"      "!^\+441865332(.*)$!sip:\1@nominet.org.uk!" .
100 20 "u" "E2U+pstn:tel" "!^(.*)$!tel:\1!"                        .

Both records share order 100, so the preference decides: the E2U+sip rule at preference 10 is tried before the E2U+pstn:tel rule at preference 20. The first regexp matches +441865332 and captures the remaining digits, 244, so the input +441865332244 becomes sip:244@nominet.org.uk. The second regexp captures the whole number and produces tel:+441865332244, a plain telephone URI for a client that cannot place a SIP call. You can run this lookup with our NAPTR tool by entering the e164.arpa name as the domain.

Beyond a handful of countries, public ENUM under e164.arpa was never widely deployed, and most countries never delegated their prefix. The same mechanism is very much alive in private ENUM. Carriers and PBX vendors run their own ENUM trees on internal domains for least-cost routing and number portability, using the same record format shown above.

NAPTR comes first. An SRV lookup requires the client to already know the service and protocol labels it wants, so _sip._tcp.example.com can only be queried once the client has decided on TCP. A NAPTR lookup is made at the bare domain, and the domain answers with the list of transports it supports and the order it prefers them in.

Use SRV alone when the service and protocol are fixed by the application, as they are for Minecraft, Autodiscover and Active Directory. Use NAPTR when transport selection belongs to the domain owner rather than the client, which is the case for SIP, and when the input is a telephone number rather than a domain name, which is the case for ENUM.

NAPTR is also the more expensive record to publish and to consume. It adds a round trip, its rules are harder to write correctly, and client library support is patchier than it is for SRV. If your service does not need transport discovery, publish SRV and stop there. Our SRV lookup page explains how the SRV half of the chain behaves.

Windows has no built-in way to query a NAPTR record. nslookup on Windows does not accept NAPTR as a type, and PowerShell's Resolve-DnsName does not include NAPTR in its -Type list either. Both can query SRV and MX records, but for NAPTR you need dig under WSL, a BIND install, or the DNSX API, which needs nothing installed.

# WSL (Ubuntu): install dig, then query as on Linux
sudo apt install dnsutils
dig NAPTR sip2sip.info +short

# Any Windows shell: the full chain as JSON
curl "https://api.dnsx.dev/dns/naptr/sip2sip.info?flow=1"

macOS ships with dig, so a NAPTR query works from Terminal without installing anything. If your version is missing it, Homebrew's bind package provides it. Add an @ resolver address to ask a specific public resolver instead of the system one.

dig NAPTR sip2sip.info +short
dig -t NAPTR sip2sip.info @8.8.8.8
brew install bind                        # only if dig is missing

On Linux, dig comes from the bind-utils package on Fedora and RHEL and the dnsutils package on Debian and Ubuntu. kdig from knot-dnsutils and drill from ldns understand NAPTR too. Piping the DNSX API through jq gives the whole chain, SRV and A/AAAA included, as JSON.

dig NAPTR sip2sip.info +short
dig -t NAPTR sip2sip.info @8.8.8.8       # ask a specific resolver
kdig -t NAPTR sip2sip.info               # knot-dnsutils
drill NAPTR sip2sip.info                 # ldns
curl "https://api.dnsx.dev/dns/naptr/sip2sip.info?flow=1" | jq .

One thing to watch when reading dig output: an empty regexp or replacement field prints as a bare pair of quotes or a lone dot, which is easy to misread as a broken record. Nothing is wrong with it. One of the two fields is meant to be empty in every valid NAPTR record.