not appropriate to use DNS to maintain information on a per-resource
   basis. First of all, DNS was never intended to handle that many
   records. Second, the limited record size is inappropriate for catalog
   information. Third, domain names are not appropriate as URNs.

   Therefore our approach is to use DNS to locate "resolvers" that can
   provide information on individual resources, potentially including
   the resource itself. To accomplish this, we "rewrite" the URI into a
   domain name following the rules provided in NAPTR records. Rewrite
   rules provide considerable power, which is important when trying to




 
RFC 2168            Resolution of URIs Using the DNS           June 1997


   meet the goals listed above. However, collections of rules can become
   difficult to understand. To lessen this problem, the NAPTR rules are
   *always* applied to the original URI, *never* to the output of
   previous rules.

   Locating a resolver through the rewrite procedure may take multiple
   steps, but the beginning is always the same. The start of the URI is
   scanned to extract its colon-delimited prefix. (For URNs, the prefix
   is always "urn:" and we extract the following colon-delimited
   namespace identifier [3]). NAPTR resolution begins by taking the
   extracted string, appending the well-known suffix ".urn.net", and
   querying the DNS for NAPTR records at that domain name.  Based on the
   results of this query, zero or more additional DNS queries may be
   needed to locate resolvers for the URI. The details of the
   conversation between the client and the resolver thus located are
   outside the bounds of this draft. Three brief examples of this
   procedure are given in the next section.

   The NAPTR RR provides the level of indirection needed to keep the
   naming system independent of the resolution system, its protocols,
   and services.  Coupled with the new SRV resource record proposal[4]
   there is also the potential for replicating the resolver on multiple
   hosts, overcoming some of the most significant problems of URLs. This
   is an important and subtle point. Not only do the NAPTR and SRV
   records allow us to replicate the resource, we can replicate the
   resolvers that know about the replicated resource. Preventing a
   single point of failure at the resolver level is a significant
   benefit. Separating the resolution procedure from the way names are
   constructed has additional benefits.  Different resolution procedures
   can be used over time, and resolution procedures that are determined
   to be useful can be extended to deal with additional namespaces.

Caveats
=======

   The NAPTR proposal is the first resolution procedure to be considered
   by the URN-WG. There are several concerns about the proposal which
   have motivated the group to recommend it for publication as an
   Experimental rather than a standards-track RFC.

   First, URN resolution is new to the IETF and we wish to gain
   operational experience before recommending any procedure for the
   standards track. Second, the NAPTR proposal is based on DNS and
   consequently inherits concerns about security and administration. The
   recent advancement of the DNSSEC and secure update drafts to Proposed
   Standard reduce these concerns, but we wish to experiment with those
   new capabilities in the context of URN administration.  A third area
   of concern is the potential for a noticeable impact on the DNS.  We




 
RFC 2168            Resolution of URIs Using the DNS           June 1997


   believe that the proposal makes appropriate use of caching and
   additional information, but it is best to go slow where the potential
   for impact on a core system like the DNS is concerned. Fourth, the
   rewrite rules in the NAPTR proposal are based on regular expressions.
   Since regular expressions are difficult for humans to construct
   correctly, concerns exist about the usability and maintainability of
   the rules. This is especially true where international character sets
   are concerned. Finally, the URN-WG is developing a requirements
   document for URN Resolution Services[15], but that document is not
   complete. That document needs to precede any resolution service
   proposals on the standards track.

Terminology
===========

   "Must" or "Shall" - Software that does not behave in the manner that
              this document says it must is not conformant to this
              document.
   "Should" - Software that does not follow the behavior that this
              document says it should may still be conformant, but is
              probably broken in some fundamental way.
   "May" -    Implementations may or may not provide the described
              behavior, while still remaining conformant to this
              document.

Brief overview and examples of the NAPTR RR: