rfc2168.txt

bind-3.2.

Network Working Group                                       R. Daniel
Request for Comments: 2168             Los Alamos National Laboratory
Category: Experimental                                    M. Mealling
                                              Network Solutions, Inc.
                                                            June 1997


               Resolution of Uniform Resource Identifiers
                      using the Domain Name System

Status of this Memo
===================

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract:
=========

   Uniform Resource Locators (URLs) are the foundation of the World Wide
   Web, and are a vital Internet technology. However, they have proven
   to be brittle in practice. The basic problem is that URLs typically
   identify a particular path to a file on a particular host. There is
   no graceful way of changing the path or host once the URL has been
   assigned. Neither is there a graceful way of replicating the resource
   located by the URL to achieve better network utilization and/or fault
   tolerance. Uniform Resource Names (URNs) have been hypothesized as a
   adjunct to URLs that would overcome such problems. URNs and URLs are
   both instances of a broader class of identifiers known as Uniform
   Resource Identifiers (URIs).

   The requirements document for URN resolution systems[15] defines the
   concept of a "resolver discovery service". This document describes
   the first, experimental, RDS. It is implemented by a new DNS Resource
   Record, NAPTR (Naming Authority PoinTeR), that provides rules for
   mapping parts of URIs to domain names.  By changing the mapping
   rules, we can change the host that is contacted to resolve a URI.
   This will allow a more graceful handling of URLs over long time
   periods, and forms the foundation for a new proposal for Uniform
   Resource Names.









Daniel & Mealling             Experimental                      [Page 1]

RFC 2168            Resolution of URIs Using the DNS           June 1997


   In addition to locating resolvers, the NAPTR provides for other
   naming systems to be grandfathered into the URN world, provides
   independence between the name assignment system and the resolution
   protocol system, and allows multiple services (Name to Location, Name
   to Description, Name to Resource, ...) to be offered.  In conjunction
   with the SRV RR, the NAPTR record allows those services to be
   replicated for the purposes of fault tolerance and load balancing.

Introduction:
=============

   Uniform Resource Locators have been a significant advance in
   retrieving Internet-accessible resources. However, their  brittle
   nature over time has been recognized for several years. The Uniform
   Resource Identifier working group proposed the development of Uniform
   Resource Names to serve as persistent, location-independent
   identifiers for Internet resources in order to overcome most of the
   problems with URLs. RFC-1737 [1] sets forth requirements on URNs.

   During the lifetime of the URI-WG, a number of URN proposals were
   generated. The developers of several of those proposals met in a
   series of meetings, resulting in a compromise known as the Knoxville
   framework.  The major principle behind the Knoxville framework is
   that the resolution system must be separate from the way names are
   assigned. This is in marked contrast to most URLs, which identify the
   host to contact and the protocol to use. Readers are referred to [2]
   for background on the Knoxville framework and for additional
   information on the context and purpose of this proposal.

   Separating the way names are resolved from the way they are
   constructed provides several benefits. It allows multiple naming
   approaches and resolution approaches to compete, as it allows
   different protocols and resolvers to be used. There is just one
   problem with such a separation - how do we resolve a name when it
   can't give us directions to its resolver?

   For the short term, DNS is the obvious candidate for the resolution
   framework, since it is widely deployed and understood. However, it is
   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



Daniel & Mealling             Experimental                      [Page 2]

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                      [Page 3]

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:
============================================

   A detailed description of the NAPTR RR will be given later, but to
   give a flavor for the proposal we first give a simple description of
   the record and three examples of its use.

   The key fields in the NAPTR RR are order, preference, service, flags,
   regexp, and replacement:

   * The order field specifies the order in which records MUST be
     processed when multiple NAPTR records are returned in response to a
     single query.  A naming authority may have delegated a portion of
     its namespace to another agency. Evaluating the NAPTR records in
     the correct order is necessary for delegation to work properly.

   * The preference field specifies the order in which records SHOULD be
     processed when multiple NAPTR records have the same value of
     "order".  This field lets a service provider specify the order in
     which resolvers are contacted, so that more capable machines are
     contacted in preference to less capable ones.





Daniel & Mealling             Experimental                      [Page 4]

RFC 2168            Resolution of URIs Using the DNS           June 1997


   * The service field specifies the resolution protocol and resolution
     service(s) that will be available if the rewrite specified by the
     regexp or replacement fields is applied. Resolution protocols are
     the protocols used to talk with a resolver. They will be specified
     in other documents, such as [5]. Resolution services are operations
     such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC),
     etc.  These will be discussed in the URN Resolution Services
     document[6], and their behavior in a particular resolution protocol
     will be given in the specification for that protocol (see [5] for a
     concrete example).

   * The flags field contains modifiers that affect what happens in the
     next DNS lookup, typically for optimizing the process. Flags may
     also affect the interpretation of the other fields in the record,
     therefore, clients MUST skip NAPTR records which contain an unknown
     flag value.

   * The regexp field is one of two fields used for the rewrite rules,
     and is the core concept of the NAPTR record. The regexp field is a
     String containing a sed-like substitution expression. (The actual
     grammar for the substitution expressions is given later in this
     draft). The substitution expression is applied to the original URN
     to determine the next domain name to be queried. The regexp field
     should be used when the domain name to be generated is conditional
     on information in the URI. If the next domain name is always known,
     which is anticipated to be a common occurrence, the replacement
     field should be used instead.

   * The replacement field is the other field that may be used for the
     rewrite rule. It is an optimization of the rewrite process for the
     case where the next domain name is fixed instead of being
     conditional on the content of the URI. The replacement field is a
     domain name (subject to compression if a DNS sender knows that a
     given recipient is able to decompress names in this RR type's RDATA
     field). If the rewrite is more complex than a simple substitution
     of a domain name, the replacement field should be set to . and the
     regexp field used.