Guide
NAPTR records: rewrite rules for SIP, ENUM and similar services
Most record types point to a thing. A NAPTR record points to a rule: it takes a name, applies a pattern and says what to look up next. The format is more complex than anything else in everyday DNS, and the usual reason to look at one is to debug how a SIP phone finds a provider, or how an ENUM service maps a telephone number. The page parses each record into its fields and describes the next step.
The six fields
Every record carries, in order: order and preference, two 16-bit numbers; flags, a short string; service, naming the protocol and resolution method; a regular expression that rewrites the input into a final result; and a replacement, a domain name used when the regular expression is empty. RFC 3403 describes the format. Exactly one of regular expression and replacement is normally used. The page shows an empty expression as “(empty)” and prints the replacement name.
Order, preference and flags
A client sorts the records by order first and works through them in ascending sequence. Within the same order it sorts by preference, but preference is advisory. The flags say what the client does with the result. s means the replacement is the name of an SRV record, which is looked up next to get a host and port. a means look up an address record directly. u means the regular expression produces a URI, the end of the chain. p means the processing is application-specific. An empty flags field means the client must continue with another NAPTR lookup.
Where NAPTR is used
SIP uses it to choose between transports for a domain (RFC 3263): the NAPTR records offer secure TCP, plain TCP and UDP in a priority order, each pointing to an SRV record. ENUM turns telephone numbers into URIs by looking up NAPTR records under e164.arpa. A few other systems, such as some roaming and content-routing schemes, use them. Most domains have none, and the page says so in a plain sentence.
Reading the result
The table has columns for order, preference, flags (with an explanation such as “Next lookup is an SRV record”), service, regular expression, replacement and TTL. The records appear sorted in the order a client would use them. Cloudflare returns text fields in quotes and Google without; the parser accepts both, so the table is the same whichever resolver you pick.
A worked example
Press Sample to look up sip2sip.info. When this guide was reviewed it had three NAPTR records, all with preference 100 and flag s and an empty regular expression. Order 5 had service SIPS+D2T and the replacement _sips._tcp.sip2sip.info, order 10 had SIP+D2T with _sip._tcp.sip2sip.info, and order 20 had SIP+D2U with _sip._udp.sip2sip.info. A SIP client that prefers secure transport follows the first, looks up the SRV record at that name and connects to the host and port it names; the SRV Record Lookup shows that next step.
Limits
The page reads and explains the records but does not run the regular expressions or complete a SIP or ENUM resolution. It looks up the exact name you enter; for ENUM you must build the e164.arpa name yourself. Most ordinary domains return no NAPTR records, which is normal. Combine it with the DNS Lookup for the full picture of a domain.
Related tools
- SRV Record Lookup resolves the service name a NAPTR replacement points to.
- DNS Lookup lists NAPTR among many record types.
- TXT Record Lookup shows other text-based DNS data.
- Port Number Lookup names the standard ports for SIP and SIPS.
Checked against the current version of the NAPTR Lookup on .