rfc2915.txt

bind-3.2.


RFC 2915                      NAPTR DNS RR                September 2000


   Regexp
      A STRING containing a substitution expression that is applied to
      the original string held by the client in order to construct the
      next domain name to lookup.  The grammar of the substitution
      expression is given in the next section.

      The regular expressions MUST NOT be used in a cumulative fashion,
      that is, they should only be applied to the original string held
      by the client, never to the domain name produced by a previous
      NAPTR rewrite.  The latter is tempting in some applications but
      experience has shown such use to be extremely fault sensitive,
      very error prone, and extremely difficult to debug.

   Replacement
      The next NAME to query for NAPTR, SRV, or address records
      depending on the value of the flags field.  This 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

   The content of the regexp field is a substitution expression.  True
   sed(1) and Perl style substitution expressions are not appropriate
   for use in this application for a variety of reasons stemming from
   internationalization requirements and backref limitations, therefore
   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 it is possible for the regexp field to be improperly specified,
   such that a non-conforming domain-name can be constructed, client
   software SHOULD verify that the result is a legal DNS domain-name
   before making queries on it.



Mealling & Daniel           Standards Track                     [Page 7]

RFC 2915                      NAPTR DNS RR                September 2000


   Backref expressions in the repl portion of the substitution
   expression are replaced by the (possibly empty) string of characters
   enclosed by '(' and ')' in the ERE portion of the substitution
   expression. N is a single digit from 1 through 9, inclusive.  It
   specifies the N'th backref expression, the one that begins with the
   N'th '(' and continues 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 indicates that 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.  Since escaped
   occurrences of the delimiter character will be interpreted as
   occurrences of that character, digits MUST NOT be used as delimiters.
   Backrefs would be confused with literal digits were this 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 allows NAPTR records to
   incrementally specify a complete rule.  These incremental rules can
   be delegated which allows other entities to specify rules so that one
   entity does not need to understand _all_ rules.

   The algorithm starts with a string and some known key (domain).
   NAPTR records for this key are retrieved, those with unknown Flags or
   inappropriate Services are 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:



Mealling & Daniel           Standards Track                     [Page 8]

RFC 2915                      NAPTR DNS RR                September 2000


   o  it has a Replacement field value instead of a Regexp field value.

   o  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 for 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 since it is the method by which
   complex rules are 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 before hand.  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 if 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
   if that records 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.  In this case the client isn't
   asking a question but is instead attempting to get at information
   that it has been told exists in an SRV record at that particular
   domain-name.  While this usage of SRV is slightly different than the
   SRV authors originally intended it does not break any of the
   assumptions concerning 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





Mealling & Daniel           Standards Track                     [Page 9]

RFC 2915                      NAPTR DNS RR                September 2000


   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 and the expected
   output and its use are specified by documents that define what
   applications the NAPTR record and algorithm are used for.  Any
   document that defines such an application must define the following:

   o  The first known domain-name or how to build it

   o  The valid Services and Protocols

   o  What the expected use is for the output of the last rewrite

   o  The validity and/or behavior of any 'P' flag protocols.

   o  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:[e-mail]

   (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, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first
   'known' key in the NAPTR algorithm.  The NAPTR records for
   cid.urn.arpa looked up and return a single record:



Mealling & Daniel           Standards Track                    [Page 10]

RFC 2915                      NAPTR DNS RR                September 2000


   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 names 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, and 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.

   telling us three hosts that could actually do the resolution, and
   giving 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



Mealling & Daniel           Standards Track                    [Page 11]

RFC 2915                      NAPTR DNS RR                September 2000


   character, literal occurances 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.  Assume we have the URL for a very popular piece of
   software that the publisher wishes to mirror at multiple sites around
   the world:

   Using the rules specified for this application we extract the prefix,
   "http", and lookup 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 information
   on the hosts that foo.com has designated to be its mirror sites.  The
   client can then pick one for the user.




Mealling & Daniel           Standards Track                    [Page 12]

RFC 2915                      NAPTR DNS RR                September 2000