Resolution of Uniform Resource Identifiers using the Domain Name System
RFC 2168

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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