Skip to content
Control Plane Labs

NAPTR record

Rewrites a name into a URI or another lookup key, using the DDDS regular-expression algorithm.

Last updated July 27, 2026

Zone-file example

example.com.   3600   IN   NAPTR   100 10 "S" "SIP+D2T" "" _sip._tcp.example.com.

Typical uses

  • ENUM, mapping E.164 telephone numbers to SIP or tel URIs
  • SIP transport selection before the SRV lookup
  • S-NAPTR and U-NAPTR application service discovery in telecom stacks
  • Legacy URN resolution, which is where the DDDS framework originated

When it breaks, check

  • Order is evaluated first and is mandatory; preference only ranks equal-order records
  • The regexp and replacement fields are mutually exclusive — exactly one must be empty
  • Zone files need the backslashes in a regexp doubled, which is where most syntax errors come from
  • Flags are case-insensitive single characters; S, A, U, and P are the ones in use

What the NAPTR record does

NAPTR exists because some lookups need a transformation rather than an answer. A DDDS application feeds a string into the database, gets back rules, applies the first matching rule to produce a new string, and either stops with a terminal result or loops with that string as input. NAPTR stores those rules, which makes reading one in isolation close to meaningless: only the application definition says what the input string is and when to stop.

Unless you run ENUM or SIP infrastructure you will never author one.

Zone-file and wire format

Six fields in order: order preference flags service regexp replacement. Order is processed strictly lowest first; preference only ranks records sharing an order. Flags terminate or continue the algorithm: "S" means the result is an SRV owner name, "A" an address record, "U" a URI produced by the regexp. The regexp field is a delimited substitution, conventionally !pattern!replacement!, with backreferences like \1 — and every backslash must be doubled in a zone file. Regexp and replacement exclude each other.

; owner       order pref flags service      regexp  replacement
example.com. IN NAPTR 100 10 "S" "SIP+D2T" "" _sip._tcp.example.com.
example.com. IN NAPTR 102 10 "S" "SIP+D2U" "" _sip._udp.example.com.

; a terminal "u" rule: regexp is used, so replacement must be "."
; note the doubled backslash a zone file needs for a \1 backreference
4.3.2.1.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .

; "S", "A", and "U" flags are terminal; an empty flag means loop again.

Common uses

Two deployments account for essentially all NAPTR traffic. ENUM maps a telephone number into the e164.arpa tree, digit-reversed and dot-separated, using "u"-flagged records to rewrite it into a SIP or tel URI. SIP server location runs the other way: before querying SRV, a proxy fetches NAPTR records to learn which transports the far end supports, then follows the "S" flag to the matching SRV record. Newer protocols skip this, since NAPTR-then-SRV is slow and the regexp field is hard to implement safely.

Troubleshooting

Read the fields in the order the algorithm uses them, not left to right. Sort by order, filter by the service field, then check the flag to learn what the result even is. A record with both a regexp and a replacement is malformed.

Escaping is the other reliable source of pain. The protocol sees one backslash, a zone file needs two, and provider forms differ on whether they escape for you. Dump the record with dig and apply the substitution by hand before blaming anything else.

# SIP transport discovery: NAPTR first, then the SRV it names
dig example.com NAPTR +noall +answer

# ENUM: a phone number becomes a reversed digit string under e164.arpa
dig 0.0.1.0.5.5.5.1.e164.arpa NAPTR +short

# follow the "S" flag to its target
dig _sip._tcp.example.com SRV +short

The defining RFC

NAPTR is type 35, currently defined by RFC 3403, the DNS database for DDDS, which supersedes the earlier standalone NAPTR documents. It is part three of five: RFC 3401 is the overview and RFC 3402 the algorithm and rewrite rules, both of which RFC 3403 assumes. URI resolution is RFC 3404, ENUM is RFC 6116, and SIP server location is RFC 3263 §4.1. Inspect a record with the DNS lookup tool.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types