RFC 2168 (rfc2168) - Page 3 of 20

Resolution of Uniform Resource Identifiers using the Domain Name System

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



Daniel & Mealling             Experimental