RFC 2168 (rfc2168) - Page 3 of 20
Resolution of Uniform Resource Identifiers using the Domain Name System
Alternative Format: Original Text Document
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