RFC 2915 (rfc2915) - Page 3 of 18
The Naming Authority Pointer (NAPTR) DNS Resource Record
Alternative Format: Original Text Document
RFC 2915 NAPTR DNS RR September 2000
The final result is a RR that has several fields that interact in a
non-trivial but implementable way. This document specifies those
fields and their values.
This document does not define applications that utilizes this rewrite
functionality. Instead it specifies just the mechanics of how it is
done. Why its done, what the rules concerning the inputs, and the
types of rules used are reserved for other documents that fully
specify a particular application. This separation is due to several
different applications all wanting to take advantage of the rewrite
rule lookup process. Each one has vastly different reasons for why
and how it uses the service, thus requiring that the definition of
the service be generic.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119.
All references to Uniform Resource Identifiers in this document
adhere to the 'absoluteURI' production of the "Collected ABNF"
found in RFC 2396 [9]. Specifically, the semantics of URI
References do not apply since the concept of a Base makes no sense
here.
2. NAPTR RR Format
The format of the NAPTR RR is given below. The DNS type code [1] for
NAPTR is 35.
Domain TTL Class Type Order Preference Flags Service Regexp
Replacement
Domain
The domain name to which this resource record refers. This is the
'key' for this entry in the rule database. This value will either
be the first well known key (.uri.arpa for example) or
a new key that is the output of a replacement or regexp rewrite.
Beyond this, it has the standard DNS requirements [1].
TTL
Standard DNS meaning [1].
Class
Standard DNS meaning [1].
Type
The Type Code [1] for NAPTR is 35.
Mealling & Daniel Standards Track