The Naming Authority Pointer (NAPTR) DNS Resource Record
obsoleted by
- rfc-3401 — Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS
- rfc-3402 — Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
- rfc-3403 — Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
- rfc-3404 — Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)
updates
- rfc-2168 — Resolution of Uniform Resource Identifiers using the Domain Name System
Extracted elements (26)
Regexp rules are explicitly prohibited from cumulative application because experience showed that applying rewrites to the output of prior rewrites is extremely fault-sensitive, very error-prone, and extremely difficult to debug. All regexps apply only to the original client-held string.
Regular expressions were chosen for the Regexp field because of their compactness-to-expressivity ratio, allowing a great deal of information to be encoded in a relatively small DNS packet. True sed(1) and Perl-style expressions were rejected due to internationalization requirements and backref limitations.
The NAPTR looping delegation model allows complex resolution rules to be broken into manageable delegated chunks, so no single entity needs to understand all rules in a resolution chain. This is the core architectural rationale for NAPTR's multi-step iterative design.
Backslashes in a regexp must be entered twice in a DNS zone master file in order to appear once in query responses due to DNS escaping rules. This double-escaping requirement may not have been tested by all DNS server implementors.
If the lookup following a NAPTR rewrite fails, clients are strongly encouraged to report failure rather than backing up to pursue other rewrite paths, to avoid confusing and unreliable fallback behavior.
When the 'A' flag is used, the specified protocol must be running on its default port because NAPTR records contain no port specification field. This contrasts with 'S' flag SRV-directed lookups where port information is carried in the SRV record.
A protocol MUST be specified in the Service field if the Flags field states the NAPTR is terminal. If a protocol is specified but the record is not terminal, the next lookup MUST be for a NAPTR record.
Among NAPTR records with equal Order values, records SHOULD be processed in ascending Preference order. A client MAY consider records with higher Preference if it has a reason such as not understanding the preferred protocol or service.
Implementors MUST NOT assume the Flags field contains only 0 or 1 characters, since multiple flags may be permitted in future versions. If a client encounters a record with an unknown flag, it MUST ignore that record and move to the next, even overriding the Order field.
NAPTR records MUST be processed in ascending Order field value. Once a matching record is found, the client MUST NOT consider any NAPTR records with a higher Order value (except as noted for Flags).
The first matching NAPTR record MUST be the one used. Clients MUST process multiple NAPTR records in Order field sequence and MUST NOT simply use the first record that offers a known protocol/service combination.
The 'i' flag in the substitution expression indicates that ERE matching SHALL be performed case-insensitively. Backref replacements MAY be normalized to lower case when the 'i' flag is given.
The regexp field MUST follow the specified substitution expression grammar using POSIX ERE. The result of applying it MUST be either a valid DNS domain-name syntax or a URI (if the 'U' flag is present). Client software SHOULD verify the result is a legal DNS domain-name before querying.
The Regexp field MUST NOT be applied cumulatively; regular expressions MUST only be applied to the original string held by the client, never to the domain name produced by a previous NAPTR rewrite.
The Replacement field MUST be a fully qualified domain name. Name compression MUST NOT be used for this field unless permitted by future standards action.
When the 'S' flag directs a SRV lookup, the domain-name from the NAPTR record MUST be used in SRV queries with NO transformations. NAPTR applications using SRV MUST NOT attempt to interpret or restructure these domain names according to the SRV specification's query domain conventions.
Four terminal or delegating flags are defined: 'S' (next lookup is SRV), 'A' (next lookup is A/AAAA/A6 address record), 'U' (Regexp output is a URI, no further DNS lookup), and 'P' (protocol-specific algorithm takes over). S, A, U, and P are mutually exclusive.
The NAPTR DNS resource record has type code 35 and contains six fields: Order (16-bit unsigned integer), Preference (16-bit unsigned integer), Flags (character-string), Service (character-string), Regexp (character-string), and Replacement (domain-name).
The Service field uses the ABNF grammar: service_field = [[protocol] *('+' rs)], where protocol and rs are each limited to 32 characters and must start with an alphabetic character. Service and protocol labels are drawn from [A-Z0-9] and are case-insensitive. An empty string is also a valid Service field value.
Extending the valid values of the Flags field beyond S, A, U, and P requires a published specification approved by the IESG. Values for the Services field are determined per application and must likewise be specified in an IESG-approved published specification.
Interactions between NAPTR records and DNSSEC were noted as under study at publication time; NAPTR records were expected to be signed with SIG records once DNSSEC deployment matured.
NAPTR specifies how to locate a service but not how communication with that service takes place. Significant security considerations for the actual communication protocols are outside the scope of this document and must be addressed by those individual protocol specifications.
Regular expressions in NAPTR records should be checked for sanity before use and MUST NOT be blindly passed to interpreters such as Perl. The rewrite rules expose identifiers from other namespaces to the same DNS-based attacks as normal domain names.
The NAPTR algorithm loops: starting with a string and key domain, retrieve NAPTR records, discard records with unknown flags or inappropriate Services, sort by Order then Preference, and find the first matching record (Replacement present or Regexp matches the string). Apply the rule and use the resulting domain as the new key for the next iteration. Terminal flags (S, A, U) or P halt or redirect the loop.
The NAPTR DNS packet encoding places ORDER and PREFERENCE as 16-bit fields, followed by FLAGS, SERVICES, and REGEXP as <character-string> encodings (per RFC 1035), and REPLACEMENT as a <domain-name> encoding. ORDER and PREFERENCE are 16-bit unsigned integers ranging 0–65535.
The Regexp field contains a substitution expression with grammar: subst_expr = delim-char ere delim-char repl delim-char *flags, where ere is a POSIX Extended Regular Expression, repl may include backreferences (\1–\9), and digits MUST NOT be used as delimiters to avoid confusion with backrefs.