NAPTR Lookup

A NAPTR record (Naming Authority Pointer) is a DNS resource record that holds a rewrite rule rather than an address. Where an A record answers "where is this host", a NAPTR record answers "which services does this domain offer, and what should I look up next to reach them". 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.

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 at all, RFC 3263 tells the client to skip straight to SRV and try _sips._tcp, _sip._tcp and _sip._udp in turn. 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 for you 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. You get to see whose network the chain actually lands on, not just that it resolves.

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, E2U+pstn. And the replacement field is a single dot, because the regexp field is doing the work.

The regexp !^.*$!sip:[email protected]! matches the whole input and replaces it with a fixed SIP address. More interesting zones use backreferences. The regexp !^\+1(.*)$!sip:\[email protected]! 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.

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 exactly the record format above.

NAPTR comes first, and it exists to answer a question SRV cannot. An SRV lookup requires the client to already know the service and protocol labels it wants: _sip._tcp.example.com is only queryable if 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 actually supports and the order it prefers them in.

So 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 not a domain name at all, 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. See the SRV record lookup page for how the SRV half of the chain behaves.

One gotcha when reading dig output directly: 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. Exactly one of the two fields is meant to be empty in every valid NAPTR record.