RFC 2915

The Naming Authority Pointer (NAPTR) DNS Resource Record

📅 published September 2000, from ietf

RFC 2915: The Naming Authority Pointer (NAPTR) DNS Resource Record 🎀

okay bestie, RFC 2915 is a Standards Track doc from September 2000 🦋 It's by M. Mealling (Network Solutions, Inc.) and R. Daniel (DATAFUSION, Inc.). It updates RFC 2168, specifically the parts about defining NAPTR records and how non-URI-specific applications might use them. It doesn't list anything it obsoletes 💅

Status of This Memo

this doc is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements 💬 for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒

Abstract

so this doc describes a Domain Name System (DNS) resource record that holds a regular expression based rewrite rule ✨ You apply that rule to an existing string and it spits out a new domain label or Uniform Resource Identifier (URI) 🪄 Depending on the flags field of the record, that output can either get used in more queries for Naming Authority Pointer (NAPTR) resource records (to delegate the name lookup), or be the final answer for the whole process you're running (like a resolution server for URI resolution, or a service URI for ENUM style e.164 number to URI mapping, etc) 🧚

This lets DNS look up services for a whole bunch of resource names (including URIs) that aren't in domain name syntax, which is so iconic 👑 The reasons range from URN Resource Discovery Systems all the way to moving out-of-date services over to new domains 🚚

This doc updates the parts of RFC 2168 that deal with the definition of NAPTR records and how other, non-URI specific applications might use NAPTR 🫶

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  NAPTR RR Format  . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Substitution Expression Grammar  . . . . . . . . . . . . . .   7
   4.  The Basic NAPTR Algorithm  . . . . . . . . . . . . . . . . .   8
   5.  Concerning How NAPTR Uses SRV Records  . . . . . . . . . . .   9
   6.  Application Specifications . . . . . . . . . . . . . . . . .  10
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.1 Example 1  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.2 Example 2  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.3 Example 3  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  DNS Packet Format  . . . . . . . . . . . . . . . . . . . . .  13
   9.  Master File Format . . . . . . . . . . . . . . . . . . . . .  14
   10. Advice for DNS Administrators  . . . . . . . . . . . . . . .  14
   11. Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
   13. Security Considerations  . . . . . . . . . . . . . . . . . .  15
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  16
       References . . . . . . . . . . . . . . . . . . . . . . . . .  16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
       Full Copyright Statement . . . . . . . . . . . . . . . . . .  18

1. Introduction ✨

okay so this RR was originally cooked up by the URN Working Group [3] 💅 The goal was to encode rule-sets in DNS so the delegated parts of a URI could be broken down in a way that they could be changed and re-delegated over time 🔄 The result was a Resource Record with a regular expression that a client program uses to rewrite a string into a domain name. Regular expressions got picked for their compactness to expressivity ratio, which means a LOT of information can fit into a pretty small DNS packet 🤌

rewriting a string according to the rules in a record is super useful across several different applications 🌈 This doc defines the basic assumptions that all of those applications must adhere to. It does not define the reasons the rewrite is used, what the expected outcomes are, or what they're used for. Those get specified by the applications that define how they use the NAPTR record and its algorithms within their own contexts 🦋

flags and other fields are also in the RR, and they control the rewrite procedure in different ways, or give info on how to communicate with the host at the domain name that came out of the rewrite 🧚

the final result is an RR with several fields that interact in a non-trivial but implementable way 🍓 This doc specifies those fields and their values.

this doc doesn't define the applications that use this rewrite functionality. It only specifies the mechanics of how it's done 🛠️ Why it's done, what the rules about the inputs are, and the types of rules used are all reserved for other docs that fully specify a particular application. The reason for this split is that several different applications all want to take advantage of the rewrite rule lookup process, and each one has vastly different reasons for why and how it uses the service. That's why the definition of the service has to 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 ✨

okay bestie, this is the actual shape of the record, so get ready 💅 The DNS type code [1] for NAPTR is 35 🎀

Domain TTL Class Type Order Preference Flags Service Regexp
Replacement

Domain 🌸 This is the domain name the resource record refers to. It's basically the 'key' for this entry in the rule database. The value will either be the first well known key (<something>.uri.arpa for example) or a new key that comes out of a replacement or regexp rewrite. Beyond that, 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 💜

Order 🔥 This is a 16-bit unsigned integer that says the order the NAPTR records MUST be processed in, so the rules come out in the right sequence. Low numbers go first, and once a NAPTR shows up whose rule "matches" the target, the client MUST NOT consider any NAPTRs with a higher value for order (except as noted below for the Flags field). no cap, this is the main character rule 👑

Preference ✨ This is a 16-bit unsigned integer for deciding the order of NAPTR records that have equal "order" values. They SHOULD be processed with low numbers first, high numbers after. It's kinda like the preference field in an MX record, and domain admins use it to steer clients toward more capable hosts or lighter weight protocols 🍓 A client MAY look at records with higher preference values if it has a good reason to, like not understanding the preferred protocol or service.

The big difference between Order and Preference is this: once a match is found, the client MUST NOT consider records with a different Order, but they MAY process records with the same Order and different Preferences. So Preference is how you give weight to rules that count as equal from an authority standpoint but not from a simple load balancing standpoint 🎀 iykyk

Flags 💖 This is a <character-string> holding flags that control aspects of how the fields in the record get rewritten and interpreted. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters doesn't matter.

Right now only four flags are defined: "S", "A", "U", and "P" 🌈 The "S", "A" and "U" flags mean a terminal lookup, which is giving "this is the last one, and the flag decides what happens next." The "S" flag means the next lookup should be for SRV records [4]. Check Section 5 for more on how NAPTR uses the SRV record type 🔍 "A" means the next lookup should be for an A, AAAA, or A6 record. The "U" flag means the next step isn't a DNS lookup at all. Instead, the output of the Regexp field is a URI that follows the 'absoluteURI' production in the ABNF of RFC 2396 [9]. Since some apps might use NAPTR to look up parts of URIs too, implementors should be aware this could cause loop conditions and should act accordingly 🔁 not me being careful lol

The "P" flag says the rest of the application side algorithm gets carried out in a Protocol-specific way 🦋 The new set of rules is identified by the Protocol named in the Services field. The record with the 'P' flag is the last one interpreted by the rules in this document. The new rules depend on the application they're used for and the protocol specified. For example, if the application is a URI RDS and the protocol is WIRE, then the new rules are governed by the algorithms around the WIRE HTTP specification, not this document 💅

The remaining alphabetic flags are reserved for future versions of the NAPTR specification. The numeric flags may be used for local experimentation 🧪 The S, A, U and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. (Experimental code and code that helps create NAPTRs would be more likely to throw that error than a client like a browser 🙈) It's anticipated that multiple flags will be allowed in the future, so implementers MUST NOT assume the flags field can only hold 0 or 1 characters. Finally, if a client hits a record with an unknown flag, it MUST ignore it and move to the next record. This test takes precedence even over the "order" field 😭 Since flags can control how fields are interpreted, a novel flag might change how the regexp and/or replacement fields are read, so it could become impossible to tell whether a record matched a given target 💀

The "S", "A", and "U" flags are called 'terminal' flags since they halt the looping rewrite algorithm. If none of those flags are present, clients may assume that another NAPTR RR exists at the domain name produced by the current rewrite rule ✨ Since the "P" flag specifies a new algorithm, it may or may not be 'terminal'. So the client can't assume another NAPTR exists, because that case gets decided somewhere else 🫶

DNS servers MAY interpret these flags and values and use that info to include the right SRV and A, AAAA, or A6 records in the additional information portion of the DNS packet 🧚 Clients are encouraged to check for additional information, but they are not required to do so.

Service 🌸 This specifies the service(s) available down this rewrite path. It can also name the particular protocol used to talk with a service. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified but the flags field doesn't say the NAPTR is terminal, the next lookup MUST be for a NAPTR. The client MAY choose not to do the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon 🙈

The service field can take any of the values below (using the Augmented BNF of RFC 2234 [5]):

service_field = [ [protocol] *("+" rs)]
protocol      = ALPHA *31ALPHANUM
rs            = ALPHA *31ALPHANUM
; The protocol and rs fields are limited to 32
; characters and must start with an alphabetic.

So it's an optional protocol specification followed by 0 or more resolution services, and each resolution service starts with a '+' character 🎀 Note that the empty string is also a valid service field. You'll usually see that at the start of a series of rules, when it's impossible to know which services and protocols a particular service will offer 🦋

The actual format of the service request and response is decided by the resolution protocol, and that's the subject of other documents. Protocols don't need to offer every service. The labels for service requests shall be formed from the set of characters [A-Z0-9], and the case of the alphabetic characters doesn't matter 💅

The list of "valid" protocols for any NAPTR record is any protocol that implements some or all of the services defined for a NAPTR application. Right now, THTTP [6] is the only protocol known to make that claim when this was published. Any other protocol that wants to be used has to come with documentation that specifies:

  • how it implements the services of the application
  • how it is to appear in the NAPTR record (i.e., the string id of the protocol)

The list of valid Resolution Services is defined by the documents that specify each individual NAPTR based application 🌈 It's also worth noting that the meaning of this field could change with new flags, and the current specification is oriented toward telling clients how to talk with a URN resolver 👑

Regexp ✨ This is a STRING holding a substitution expression that gets applied to the original string the client has, to build the next domain name to look up. The grammar of the substitution expression is in the next section 🔥

The regular expressions MUST NOT be used in a cumulative fashion. That means they should only be applied to the original string the client holds, never to a domain name produced by a previous NAPTR rewrite. This is tempting in some applications, but experience has shown it to be extremely fault sensitive, very error prone, and extremely hard to debug 😭

Replacement 💖 This is the next NAME to query for NAPTR, SRV, or address records, depending on the value of the flags field. It MUST be a fully qualified domain-name. Unless and until permitted by future standards action, name compression is not to be used for this field 🍓

3. Substitution Expression Grammar ✨

okay so the regexp field holds a substitution expression, and bestie, the real sed(1) and Perl style ones are a no-go here 🙈 they bring too many problems for this app, mostly because of internationalization requirements and backref limitations. So the contents of the regexp field MUST follow the grammar below:

subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
delim-char   = "/" / "!" / ... <Any non-digit or non-flag character
               other than backslash '\'. All occurances of a delim_char
               in a subst_expr must be the same character.>
ere          = POSIX Extended Regular Expression
repl         = 1 * ( OCTET /  backref )
backref      = "\" 1POS_DIGIT
flags        = "i"
POS_DIGIT    = %x31-39                 ; 0 is not an allowed backref

The definition of a POSIX Extended Regular Expression can be found in [8], section 2.8.4. 💖

The result of applying the substitution expression to the original URI MUST result in either a string that obeys the syntax for DNS domain-names [1] or a URI [9] if the Flags field contains a 'u'. Since the regexp field can be improperly specified, and a non-conforming domain-name can end up getting built, client software SHOULD verify that the result is a legal DNS domain-name before making queries on it. 🔥

Backref expressions in the repl portion get swapped out for the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion. N is a single digit from 1 through 9, inclusive. It points at the N'th backref expression, the one that begins with the N'th '(' and runs to the matching ')'. For example, the ERE

                            (A(B(C)DE)(F)G)

has backref expressions:

                            \1  = ABCDEFG
                            \2  = BCDE
                            \3  = C
                            \4  = F
                            \5..\9  = error - no matching subexpression

The "i" flag means the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given. 🦋

The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurrences of the delimiter character in a substitution expression. Escaped occurrences of the delimiter character get interpreted as occurrences of that character, so digits MUST NOT be used as delimiters. Backrefs would get confused with literal digits if that were allowed. Similarly, if flags are specified in the substitution expression, the delimiter character must not also be a flag character. 🎀

4. The Basic NAPTR Algorithm

The behavior and meaning of the flags and services assume an algorithm where the output of one rewrite is a new key that points to another rule. This looping algorithm lets NAPTR records incrementally specify a complete rule. These incremental rules can be delegated, which lets other entities write rules so that one entity doesn't need to understand _all_ rules. 🧚

The algorithm starts with a string and some known key (domain). NAPTR records for this key get retrieved, those with unknown Flags or inappropriate Services get discarded, and the remaining records are sorted by their Order field. Within each value of Order, the records are further sorted by the Preferences field. 💅

The records are examined in sorted order until a matching record is found. A record is considered a match iff:

  • it has a Replacement field value instead of a Regexp field value.
  • or the Regexp field matches the string held by the client.

The first match MUST be the match that is used. Once a match is found, the Services field is examined to see whether or not this rule advances toward the desired result. If so, the rule is applied to the target string. If not, the process halts. The domain that results from the regular expression is then used as the domain of the next loop through the NAPTR algorithm. Note that the same target string is used throughout the algorithm. ✨

This looping is extremely important, because it's how complex rules get broken down into manageable delegated chunks. The Flags fields simply determine at which point the looping should stop (or other specialized behavior). 🌈

Since flags are valid at any level of the algorithm, the degenerative case is to never loop, but to look up the NAPTR and then stop. In many specialized cases this is all that is needed. Implementors should be aware that the degenerative case should not become the common case. 💀

5. Concerning How NAPTR Uses SRV Records 🫶

When the SRV record type was originally specified, it assumed that the client did not know the specific domain-name beforehand. The client would construct a domain-name more in the form of a question than the usual case of knowing ahead of time that the domain-name should exist. I.e., if the client wants to know whether there is a TCP based HTTP server running at a particular domain, the client would construct the domain-name _http._tcp.somedomain.com and ask the DNS whether that record exists. The underscores are used to avoid collisions with potentially 'real' domain-names. 🍓

In the case of NAPTR, the actual domain-name is specified by the various fields in the NAPTR record. Here the client isn't asking a question. It's instead trying to get at information that it has been told exists in an SRV record at that particular domain-name. This usage of SRV is slightly different from what the SRV authors originally intended, but it does not break any of the assumptions about what SRV contains. Also, since the NAPTR explicitly spells out the domain-name for which an SRV exists, that domain-name MUST be used in SRV queries with NO transformations. Any given NAPTR record may result in a domain-name to be used for SRV queries that may or may not contain the SRV standardized underscore characters. NAPTR applications that make use of SRV MUST NOT attempt to understand these domains or use them according to how the SRV specification structures its query domains. 👑

6. Application Specifications

It should be noted that the NAPTR algorithm is the basic assumption about how NAPTR works. The reasons for the rewrite, along with the expected output and its use, are specified by documents that define the applications the NAPTR record and algorithm are used for. Any document that defines such an application must define the following:

  • The first known domain-name or how to build it
  • The valid Services and Protocols
  • What the expected use is for the output of the last rewrite
  • The validity and/or behavior of any 'P' flag protocols.
  • The general semantics surrounding why and how NAPTR and its algorithm are being used.

7. Examples 🎀

NOTE: These are examples only. They are taken from ongoing work and may not represent the end result of that work. They are here for pedagogical reasons only. 🙈

7.1 Example 1

NAPTR was originally specified for use with the a Uniform Resource Name Resolver Discovery System. This example details how a particular URN would use the NAPTR record to find a resolver service. 🔮

Consider a URN namespace based on MIME Content-Ids. The URN might look like this:

   urn:cid:39CB83F7.A8450130@fake.gatech.edu

(Note that this example is chosen for pedagogical purposes, and does not conform to the CID URL scheme.)

The first step in the resolution process is to find out about the CID namespace. The namespace identifier [3], 'cid', is extracted from the URN and prepended to urn.arpa. 'cid.urn.arpa' then becomes the first 'known' key in the NAPTR algorithm. The NAPTR records for cid.urn.arpa are looked up and return a single record:

cid.urn.arpa.
;;       order pref flags service        regexp           replacement
IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .

There is only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so the pattern provided in the regexp field is used. We apply that regexp to the entire URN to see if it matches, which it does. The \2 part of the substitution expression returns the string "gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal, and our next probe to DNS is for more NAPTR records where the new domain is 'gatech.edu' and the string is the same string as before. 🦋

Note that the rule does not extract the full domain name from the CID. Instead, it assumes the CID comes from a host and extracts its domain. While all hosts, such as mordred, could have their very own NAPTR, maintaining those records for all the machines at a site as large as Georgia Tech would be an intolerable burden. Wildcards are not appropriate here, since they only return results when there is no exactly matching name already in the system. 🌸

The record returned from the query on "gatech.edu" might look like:

;;       order pref flags service           regexp  replacement
 IN NAPTR 100  50  "s"  "z3950+I2L+I2C"     ""  _z3950._tcp.gatech.edu.
 IN NAPTR 100  50  "s"  "rcds+I2C"          ""  _rcds._udp.gatech.edu.
 IN NAPTR 100  50  "s"  "http+I2L+I2C+I2R"  ""  _http._tcp.gatech.edu.

Continuing with the example, note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see. After the rewrite (a simple replacement in this case), we should look up SRV records to get information on the hosts that can provide the necessary service. ⭐

Assuming we prefer the Z39.50 protocol, our lookup might return:

 ;;                        Pref Weight   Port Target
 _z3950._tcp.gatech.edu. IN SRV 0    0      1000 z3950.gatech.edu.
                         IN SRV 0    0      1000 z3950.cc.gatech.edu.
                         IN SRV 0    0      1000 z3950.uga.edu.

That tells us three hosts that could actually do the resolution, and gives us the port we should use to talk to their Z39.50 server. 💜

Recall that the regular expression used \2 to extract a domain name from the CID, and \. for matching the literal '.' characters separating the domain name components. Since '' is the escape character, literal occurrences of a backslash must be escaped by another backslash. For the case of the cid.urn.arpa record above, the regular expression entered into the master file should be "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually receives the record, the pattern will have been converted to "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i". 🫶

7.2 Example 2 ✨

Even if URN systems were in place now, there would still be a tremendous number of URLs 🌍 It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement that URNs be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc. 📚

The NAPTR RR could also be used for URLs that have already been assigned 💅 Say we have the URL for a very popular piece of software that the publisher wants to mirror at multiple sites around the world:

Using the rules specified for this application, we extract the prefix, "http", and look up NAPTR records for http.uri.arpa. This might return a record of the form:

  http.uri.arpa. IN NAPTR
  ;;  order   pref flags service      regexp             replacement
       100     90   ""      ""   "!http://([^/:]+)!\1!i"       .

This expression returns everything after the first double slash and before the next slash or colon. 🦋 (We use the '!' character to delimit the parts of the substitution expression. Otherwise we would have to use backslashes to escape the forward slashes and would have a regexp in the zone file that looked like "/http:\/\/([^\/:]+)/\1/i".).

Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return:

  www.foo.com.
  ;;       order pref flags   service  regexp     replacement
   IN NAPTR 100  100  "s"   "http+I2R"   ""    _http._tcp.foo.com.
   IN NAPTR 100  100  "s"   "ftp+I2R"    ""    _ftp._tcp.foo.com.

Looking up SRV records for http.tcp.foo.com would return info on the hosts that foo.com has designated as its mirror sites 🪞 The client can then pick one for the user. Main character energy, honestly 👑

7.3 Example 3 🎀

A non-URI example is the ENUM application, which uses a NAPTR record to map an e.164 telephone number to a URI 📞 To convert the phone number to a domain name for the first iteration, all characters other than digits are removed from the telephone number, the entire number is inverted, periods are put between each digit, and the string ".e164.arpa" is put on the left-hand side. For example, the E.164 phone number "+1-770-555-1212" converted to a domain name would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa." 🧚

For this example telephone number, we might get back the following NAPTR records:

$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
 IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@tele2.se!"     .
 IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!"  .

This application uses the same 'u' flag as the URI Resolution application. This flag states that the Rule is terminal and that the output is a URI which contains the information needed to contact that telephone service ☎️ ENUM also uses the same format for its Service field, except that it defines the 'E2U' service instead of the 'I2*' services that URI resolution uses. The example above states that the available protocols for reaching that telephone's service are either the Session Initiation Protocol or SMTP mail 💌

8. DNS Packet Format 📦

The packet format for the NAPTR record is:

                                       1  1  1  1  1  1
         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                     ORDER                     |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                   PREFERENCE                  |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                     FLAGS                     /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                   SERVICES                    /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                    REGEXP                     /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                  REPLACEMENT                  /
       /                                               /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

FLAGS: A <character-string> which contains various flags.

SERVICES: A <character-string> which contains protocol and service identifiers.

REGEXP: A <character-string> which contains a regular expression.

REPLACEMENT: A <domain-name> which specifies the new value in the case where the regular expression is a simple replacement operation.

<character-string> and <domain-name> as used here are defined in RFC1035 [1] 📖

9. Master File Format 🗂️

The master file format follows the standard rules in RFC-1035 [1]. Order and preference, being 16-bit unsigned integers, shall be an integer between 0 and 65535. The Flags, Services and Regexp fields are all quoted <character-string>s. Since the Regexp field can contain numerous backslashes, it should be treated with care. See Section 10 for how to correctly enter and escape the regular expression 🫶

10. Advice for DNS Administrators 🧠

Beware of regular expressions 💀 They are not only difficult to get correct on their own, but there is also the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers 🙈

The "a" flag allows the next lookup to be for address records (A, AAAA, A6) rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used, the specified protocol must be running on its default port 🍓

The URN Syntax draft defines a canonical form for each URN, which requires %encoding of characters outside a limited repertoire. The regular expressions MUST be written to operate on that canonical form ✨ Since international character sets will end up with extensive use of %encoded characters, regular expressions operating on them will be essentially impossible to read or write by hand 😭

11. Notes 📝

  • A client MUST process multiple NAPTR records in the order specified by the "order" field. It MUST NOT simply use the first record that provides a known protocol and service combination 🚫
  • When multiple RRs have the same "order" and all other criteria are equal, the client should use the value of the preference field to select the next NAPTR to consider. However, because it will often be the case that preferred protocols or services exist, clients may use this additional criteria to sort the records 🌈
  • If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths 🛑
  • Note that SRV RRs impose additional requirements on clients 🔥

12. IANA Considerations 🏛️

The only registration function that impacts the IANA is for the values that are standardized for the Services and Flags fields. To extend the valid values of the Flags field beyond what is specified in this document requires a published specification that is approved by the IESG 📜

The values for the Services field will be determined by the application that makes use of the NAPTR record. Those values must be specified in a published specification and approved by the IESG 🪄

13. Security Considerations 🔐

Okay, bestie, this section is serious business, so read it carefully 😤

The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed 🔏

The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem 🤷‍♀️

Regular expressions should be checked for sanity, not blindly passed to something like PERL 🚨

This document has discussed a way of locating a service, but it has not discussed any detail of how communication with that service takes place. There are significant security considerations attached to communication with a service. Those considerations are outside the scope of this document and must be addressed by the specifications for particular communication protocols 🛡️

14. Acknowledgments 🫶

The editors would like to thank Keith Moore for all his consultations during the development of this memo 💖 We would also like to thank Paul Vixie for his assistance in debugging our implementation, and for his answers to our questions. Finally, we would like to acknowledge our enormous intellectual debt to the participants in the Knoxville series of meetings, as well as to the participants in the URI and URN working groups 🌸

References 📚

  • [1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [3] Moats, R., "URN Syntax", RFC 2141, May 1997.
  • [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
  • [5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [6] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
  • [7] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
  • [8] IEEE, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
  • [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

Authors' Addresses 🖋️

Michael Mealling
Network Solutions, Inc.
505 Huntmar Park Drive
Herndon, VA  22070
US

Phone: +1 770 921 2251
EMail: michaelm@netsol.com
URI:   http://www.netsol.com


Ron Daniel
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA  94107
US

Phone: +1 415 222 0100
EMail: rdaniel@datafusion.net
URI:   http://www.datafusion.net

Okay bestie, the legal bit, but make it cute 🎀 The Internet Society owns the copyright (C) for 2000, and everyone keeps all rights reserved. 💅

You're allowed to copy this document and hand it out to others, and you can even make derivative works that comment on or explain it or help people implement it. You can publish and distribute those, in whole or in part, with no restrictions at all, as long as the copyright notice and this paragraph are still on every copy and derivative work. 🦋

The document itself can't be modified in any way, though. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The one exception is when it's needed for developing Internet standards, and then the copyright procedures in the Internet Standards process have to be followed. You're also allowed to translate it into languages other than English. 🌸

The permissions above are perpetual, meaning they're forever. The Internet Society and its successors or assigns can't take them back. 🫶

This document and everything in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. Not gonna lie, that's a lot of disclaimers, but it's standard legal stuff 💀

Acknowledgement

Shoutout to the people paying the bills 💜 Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from