As per Relevance of the word experiment, we have this rfc below:
Network Working Group R.
Request for Comments: 2168 Los Alamos National
Category: Experimental M.
Network Solutions, Inc
June 1997
Resolution of Uniform Resource
using the Domain Name
Status of this
===================
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
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
Web, and are a vital Internet technology. However, they have
to be brittle in practice. The basic problem is that URLs
identify a particular path to a file on a particular host. There
no graceful way of changing the path or host once the URL has
assigned. Neither is there a graceful way of replicating the
located by the URL to achieve better network utilization and/or
tolerance. Uniform Resource Names (URNs) have been hypothesized as
adjunct to URLs that would overcome such problems. URNs and URLs
both instances of a broader class of identifiers known as
Resource Identifiers (URIs).
The requirements document for URN resolution systems[15] defines
concept of a "resolver discovery service". This document
the first, experimental, RDS. It is implemented by a new DNS
Record, NAPTR (Naming Authority PoinTeR), that provides rules
mapping parts of URIs to domain names. By changing the
rules, we can change the host that is contacted to resolve a URI
This will allow a more graceful handling of URLs over long
periods, and forms the foundation for a new proposal for
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
naming systems to be grandfathered into the URN world,
independence between the name assignment system and the
protocol system, and allows multiple services (Name to Location,
to Description, Name to Resource, ...) to be offered. In
with the SRV RR, the NAPTR record allows those services to
replicated for the purposes of fault tolerance and load balancing
Introduction
=============
Uniform Resource Locators have been a significant advance
retrieving Internet-accessible resources. However, their
nature over time has been recognized for several years. The
Resource Identifier working group proposed the development of
Resource Names to serve as persistent, location-
identifiers for Internet resources in order to overcome most of
problems with URLs. RFC-1737 [1] sets forth requirements on URNs
During the lifetime of the URI-WG, a number of URN proposals
generated. The developers of several of those proposals met in
series of meetings, resulting in a compromise known as the
framework. The major principle behind the Knoxville framework
that the resolution system must be separate from the way names
assigned. This is in marked contrast to most URLs, which identify
host to contact and the protocol to use. Readers are referred to [2]
for background on the Knoxville framework and for
information on the context and purpose of this proposal
Separating the way names are resolved from the way they
constructed provides several benefits. It allows multiple
approaches and resolution approaches to compete, as it
different protocols and resolvers to be used. There is just
problem with such a separation - how do we resolve a name when
can't give us directions to its resolver
For the short term, DNS is the obvious candidate for the
framework, since it is widely deployed and understood. However, it
not appropriate to use DNS to maintain information on a per-
basis. First of all, DNS was never intended to handle that
records. Second, the limited record size is inappropriate for
information. Third, domain names are not appropriate as URNs
Therefore our approach is to use DNS to locate "resolvers" that
provide information on individual resources, potentially
the resource itself. To accomplish this, we "rewrite" the URI into
domain name following the rules provided in NAPTR records.
rules provide considerable power, which is important when trying
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
difficult to understand. To lessen this problem, the NAPTR rules
*always* applied to the original URI, *never* to the output
previous rules
Locating a resolver through the rewrite procedure may take
steps, but the beginning is always the same. The start of the URI
scanned to extract its colon-delimited prefix. (For URNs, the
is always "urn:" and we extract the following colon-
namespace identifier [3]). NAPTR resolution begins by taking
extracted string, appending the well-known suffix ".urn.net",
querying the DNS for NAPTR records at that domain name. Based on
results of this query, zero or more additional DNS queries may
needed to locate resolvers for the URI. The details of
conversation between the client and the resolver thus located
outside the bounds of this draft. Three brief examples of
procedure are given in the next section
The NAPTR RR provides the level of indirection needed to keep
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
hosts, overcoming some of the most significant problems of URLs.
is an important and subtle point. Not only do the NAPTR and
records allow us to replicate the resource, we can replicate
resolvers that know about the replicated resource. Preventing
single point of failure at the resolver level is a
benefit. Separating the resolution procedure from the way names
constructed has additional benefits. Different resolution
can be used over time, and resolution procedures that are
to be useful can be extended to deal with additional namespaces
=======
The NAPTR proposal is the first resolution procedure to be
by the URN-WG. There are several concerns about the proposal
have motivated the group to recommend it for publication as
Experimental rather than a standards-track RFC
First, URN resolution is new to the IETF and we wish to
operational experience before recommending any procedure for
standards track. Second, the NAPTR proposal is based on DNS
consequently inherits concerns about security and administration.
recent advancement of the DNSSEC and secure update drafts to
Standard reduce these concerns, but we wish to experiment with
new capabilities in the context of URN administration. A third
of concern is the potential for a noticeable impact on the DNS.
Daniel & Mealling Experimental [Page 3]
RFC 2168 Resolution of URIs Using the DNS June 1997
believe that the proposal makes appropriate use of caching
additional information, but it is best to go slow where the
for impact on a core system like the DNS is concerned. Fourth,
rewrite rules in the NAPTR proposal are based on regular expressions
Since regular expressions are difficult for humans to
correctly, concerns exist about the usability and maintainability
the rules. This is especially true where international character
are concerned. Finally, the URN-WG is developing a
document for URN Resolution Services[15], but that document is
complete. That document needs to precede any resolution
proposals on the standards track
===========
"Must" or "Shall" - Software that does not behave in the manner
this document says it must is not conformant to
document
"Should" - Software that does not follow the behavior that
document says it should may still be conformant, but
probably broken in some fundamental way
"May" - Implementations may or may not provide the
behavior, while still remaining conformant to
document
Brief overview and examples of the NAPTR RR
============================================
A detailed description of the NAPTR RR will be given later, but
give a flavor for the proposal we first give a simple description
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
processed when multiple NAPTR records are returned in response to
single query. A naming authority may have delegated a portion
its namespace to another agency. Evaluating the NAPTR records
the correct order is necessary for delegation to work properly
* The preference field specifies the order in which records SHOULD
processed when multiple NAPTR records have the same value
"order". This field lets a service provider specify the order
which resolvers are contacted, so that more capable machines
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
service(s) that will be available if the rewrite specified by
regexp or replacement fields is applied. Resolution protocols
the protocols used to talk with a resolver. They will be
in other documents, such as [5]. Resolution services are
such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC),
etc. These will be discussed in the URN Resolution
document[6], and their behavior in a particular resolution
will be given in the specification for that protocol (see [5] for
concrete example).
* The flags field contains modifiers that affect what happens in
next DNS lookup, typically for optimizing the process. Flags
also affect the interpretation of the other fields in the record
therefore, clients MUST skip NAPTR records which contain an
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
String containing a sed-like substitution expression. (The
grammar for the substitution expressions is given later in
draft). The substitution expression is applied to the original
to determine the next domain name to be queried. The regexp
should be used when the domain name to be generated is
on information in the URI. If the next domain name is always known
which is anticipated to be a common occurrence, the
field should be used instead
* The replacement field is the other field that may be used for
rewrite rule. It is an optimization of the rewrite process for
case where the next domain name is fixed instead of
conditional on the content of the URI. The replacement field is
domain name (subject to compression if a DNS sender knows that
given recipient is able to decompress names in this RR type's
field). If the rewrite is more complex than a simple
of a domain name, the replacement field should be set to . and
regexp field used
Daniel & Mealling Experimental [Page 5]
RFC 2168 Resolution of URIs Using the DNS June 1997
Note that the client applies all the substitutions and performs
lookups, they are not performed in the DNS servers. Note also that
is the belief of the developers of this document that regexps
rarely be used. The replacement field seems adequate for the
majority of situations. Regexps are only necessary when portions of
namespace are to be delegated to different resolvers. Finally,
that the regexp and replacement fields are, at present,
exclusive. However, developers of client software should be
that a new flag might be defined which requires values in
fields
Example 1
---------
Consider a URN that uses the hypothetical DUNS namespace.
numbers are identifiers for approximately 30 million
businesses around the world, assigned and maintained by Dunn
Bradstreet. The URN might look like
urn:duns:002372413:annual-report-1997
The first step in the resolution process is to find out about
DUNS namespace. The namespace identifier, "duns", is extracted
the URN, prepended to urn.net, and the NAPTRs for duns.urn.net
up. It might return records of the form
duns.urn.
;; order pref flags service regexp
IN NAPTR 100 10 "s" "dunslink+N2L+N2C" "" dunslink.udp.isi.dandb.
IN NAPTR 100 20 "s" "rcds+N2C" "" rcds.udp.isi.dandb.
IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" "" http.tcp.isi.dandb.
The order field contains equal values, indicating that no
delegation order has to be followed. The preference field
that the provider would like clients to use the special
protocol, followed by the RCDS protocol, and that HTTP is offered
a last resort. All the records specify the "s" flag, which will
explained momentarily. The service fields say that if we
dunslink, we will be able to issue either the N2L or N2C requests
obtain a URL or a URC (description) of the resource. The
Cataloging and Distribution Service (RCDS)[7] could be used to get
URC for the resource, while HTTP could be used to get a URL, URC,
the resource itself. All the records supply the next domain name
query, none of them need to be rewritten with the aid of
expressions
Daniel & Mealling Experimental [Page 6]
RFC 2168 Resolution of URIs Using the DNS June 1997
The general case might require multiple NAPTR rewrites to locate
resolver, but eventually we will come to the "terminal NAPTR".
we have the terminal NAPTR, our next probe into the DNS will be for
SRV or A record instead of another NAPTR. Rather than probing for
non-existent NAPTR record to terminate the loop, the flags field
used to indicate a terminal lookup. If it has a value of "s",
next lookup should be for SRV RRs, "a" denotes that A records
sought. A "p" flag is also provided to indicate that the next
is Protocol-specific, but that looking up another NAPTR will not
part of it
Since our example RR specified the "s" flag, it was terminal
Assuming our client does not know the dunslink protocol, our
action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which
tell us hosts that can provide the necessary resolution service.
lookup might return
;; Pref Weight Port
rcds.udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.
IN SRV 0 0 1000 dbmirror.com.
IN SRV 0 0 1000 ukmirror.com.
telling us three hosts that could actually do the resolution,
giving us the port we should use to talk to their RCDS server. (
reader is referred to the SRV proposal [4] for the interpretation
the fields above).
There is opportunity for significant optimization here. We can
the SRV records as additional information for terminal NAPTRs (
the A records as additional information for those SRVs). While
recursive provision of additional information is not
blessed in the DNS specifications, it is not forbidden, and BIND
take advantage of it [8]. This is a significant optimization.
conjunction with a long TTL for *.urn.net records, the average
of probes to DNS for resolving DUNS URNs would approach one
Therefore, DNS server implementors SHOULD provide
information with NAPTR responses. The additional information will
either SRV or A records. If SRV records are available, their
records should be provided as recursive additional information
Note that the example NAPTR records above are intended to
the reply the client will see. They are not quite identical to
the domain administrator would put into the zone files. For
thing, the administrator should supply the trailing '.' character
any FQDNs
Daniel & Mealling Experimental [Page 7]
RFC 2168 Resolution of URIs Using the DNS June 1997
Example 2
---------
Consider a URN namespace based on MIME Content-Ids. The URN
look like this
urn:cid:199606121851.1@mordred.gatech.
(Note that this example is chosen for pedagogical purposes, and
not conform to the recently-approved CID URL scheme.)
The first step in the resolution process is to find out about the
namespace. The namespace identifier, cid, is extracted from the URN
prepended to urn.net, and the NAPTR for cid.urn.net looked up.
might return records of the form
cid.urn.
;; order pref flags service regexp
IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" .
We have only one NAPTR response, so ordering the responses is not
problem. The replacement field is empty, so we check the
field and use the pattern provided there. We apply that regexp to
entire URN to see if it matches, which it does. The \2 part of
substitution expression returns the string "gatech.edu". Since
flags field does not contain "s" or "a", the lookup is not
and our next probe to DNS is for more NAPTR records
lookup(query=NAPTR, "gatech.edu").
Note that the rule does not extract the full domain name from
CID, instead it assumes the CID comes from a host and extracts
domain. While all hosts, such as mordred, could have their very
NAPTR, maintaining those records for all the machines at a site
large as Georgia Tech would be an intolerable burden. Wildcards
not appropriate here since they only return results when there is
exactly matching names already in the system
The record returned from the query on "gatech.edu" might look like
gatech.edu IN
;; order pref flags service regexp
IN NAPTR 100 50 "s" "z3950+N2L+N2C" "" z3950.tcp.gatech.
IN NAPTR 100 50 "s" "rcds+N2C" "" rcds.udp.gatech.
IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" http.tcp.gatech.
Daniel & Mealling Experimental [Page 8]
RFC 2168 Resolution of URIs Using the DNS June 1997
Continuing with our example, we note that the values of the order
preference fields are equal in all records, so the client is free
pick any record. The flags field tells us that these are the
NAPTR patterns we should see, and after the rewrite (a
replacement in this case) we should look up SRV records to
information on the hosts that can provide the necessary service
Assuming we prefer the Z39.50 protocol, our lookup might return
;; Pref Weight Port
z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.
IN SRV 0 0 1000 z3950.cc.gatech.
IN SRV 0 0 1000 z3950.uga.
telling us three hosts that could actually do the resolution,
giving us the port we should use to talk to their Z39.50 server
Recall that the regular expression used \2 to extract a domain
from the CID, and \. for matching the literal '.'
seperating the domain name components. Since '\' is the
character, literal occurances of a backslash must be escaped
another backslash. For the case of the cid.urn.net record above,
regular expression entered into the zone file should
"/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code
receives the record, the pattern will have been converted
"/urn:cid:.+@([^.]+\.)(.*)$/\2/i".
Example 3
---------
Even if URN systems were in place now, there would still be
tremendous number of URLs. It should be possible to develop a
resolution system that can also provide location independence
those URLs. This is related to the requirement in [1] to be able
grandfather in names from other naming systems, such as ISO
Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs
etc
The NAPTR RR could also be used for URLs that have already
assigned. Assume we have the URL for a very popular piece
software that the publisher wishes to mirror at multiple sites
the world
http://www.foo.com/software/latest-beta.
Daniel & Mealling Experimental [Page 9]
RFC 2168 Resolution of URIs Using the DNS June 1997
We extract the prefix, "http", and lookup NAPTR records
http.urn.net. This might return a record of the
http.urn.net IN
;; order pref flags service regexp
100 90 "" "" "!http://([^/:]+)!\1!i" .
This expression returns everything after the first double slash
before the next slash or colon. (We use the '!' character to
the parts of the substitution expression. Otherwise we would have
use backslashes to escape the forward slashes, and would have
regexp in the zone file that looked
"/http:\\/\\/([^\\/:]+)/\\1/i".).
Applying this pattern to the URL extracts "www.foo.com". Looking
NAPTR records for that might return
www.foo.
;; order pref flags service regexp
IN NAPTR 100 100 "s" "http+L2R" "" http.tcp.foo.
IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.tcp.foo.
Looking up SRV records for http.tcp.foo.com would return
on the hosts that foo.com has designated to be its mirror sites.
client can then pick one for the user
NAPTR RR
===============
The format of the NAPTR RR is given below. The DNS type code
NAPTR is 35.
Domain TTL Class Order Preference Flags Service
where
The domain name this resource record refers to
Standard DNS Time To Live
Standard DNS
Daniel & Mealling Experimental [Page 10]
RFC 2168 Resolution of URIs Using the DNS June 1997
A 16-bit integer specifying the order in which the
records MUST be processed to ensure correct delegation
portions of the namespace over time. Low numbers are
before high numbers, and once a NAPTR is found that "matches
a URN, the client MUST NOT consider any NAPTRs with a
value for order
A 16-bit integer which specifies the order in which
records with equal "order" values SHOULD be processed,
numbers being processed before high numbers. This is
to the preference field in an MX record, and is used so
administrators can direct clients towards more capable
or lighter weight protocols
A String giving flags to control aspects of the rewriting
interpretation of the fields in the record. Flags are
characters from the set [A-Z0-9]. The case of the
characters is not significant
At this time only three flags, "S", "A", and "P", are defined
"S" means that the next lookup should be for SRV
instead of NAPTR records. "A" means that the next
should be for A records. The "P" flag says that the
of the resolution shall be carried out in a Protocol-
fashion, and we should not do any more DNS queries
The remaining alphabetic flags are reserved. The numeric
may be used for local experimentation. The S, A, and P
are all mutually exclusive, and resolution libraries
signal an error if more than one is given. (Experimental
and code for assisting in the creation of NAPTRs would be
likely to signal such an error than a client such as
browser). We anticipate that multiple flags will be allowed
the future, so implementers MUST NOT assume that the
field can only contain 0 or 1 characters. Finally, if a
encounters a record with an unknown flag, it MUST ignore
and move to the next record. This test takes precedence
over the "order" field. Since flags can control
interpretation placed on fields, a novel flag might change
interpretation of the regexp and/or replacement fields
that it is impossible to determine if a record matched a URN
Daniel & Mealling Experimental [Page 11]
RFC 2168 Resolution of URIs Using the DNS June 1997
Specifies the resolution service(s) available down
rewrite path. It may also specify the particular protocol
is used to talk with a resolver. A protocol MUST be
if the flags field states that the NAPTR is terminal. If
protocol is specified, but the flags field does not state
the NAPTR is terminal, the next lookup MUST be for a NAPTR
The client MAY choose not to perform the next lookup if
protocol is unknown, but that behavior MUST NOT be
upon
The service field may take any of the values below (using
Augmented BNF of RFC 822[9]):
service_field = [ [protocol] *("+" rs)]
protocol = ALPHA *31
rs = ALPHA *31
// The protocol and rs fields are limited to 32
// characters and must start with an alphabetic
// The current set of "known" strings are
// protocol = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
// rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C
// / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C
i.e. an optional protocol specification followed by 0 or
resolution services. Each resolution service is indicated
an initial '+' character
Note that the empty string is also a valid service field.
will typically be seen at the top levels of a namespace,
it is impossible to know what services and protocols will
offered by a particular publisher within that name space
At this time the known protocols are rcds[7], hdl[10] (binary
UDP-based protocols), thttp[5] (a textual, TCP-
protocol), rwhois[11] (textual, UDP or TCP based),
Z39.50[12] (binary, TCP-based). More will be allowed later
The names of the protocols must be formed from the
[a-Z0-9]. Case of the characters is not significant
The service requests currently allowed will be described
more detail in [6], but in brief they are
N2L - Given a URN, return a
N2Ls - Given a URN, return a set of
N2R - Given a URN, return an instance of the resource
N2Rs - Given a URN, return multiple instances of
resource, typically encoded
multipart/alternative
Daniel & Mealling Experimental [Page 12]
RFC 2168 Resolution of URIs Using the DNS June 1997
N2C - Given a URN, return a collection of meta
information on the named resource. The format
this response is the subject of another document
N2Ns - Given a URN, return all URNs that are
identifers for the resource
L2R - Given a URL, return the resource
L2Ns - Given a URL, return all the URNs that
identifiers for the resource
L2Ls - Given a URL, return all the URLs for instances
of the same resource
L2C - Given a URL, return a description of
resource
The actual format of the service request and response will
determined by the resolution protocol, and is the subject
other documents (e.g. [5]). Protocols need not offer
services. The labels for service requests shall be formed
the set of characters [A-Z0-9]. The case of the
characters is not significant
A STRING containing a substitution expression that is
to the original URI in order to construct the next domain
to lookup. The grammar of the substitution expression is
in the next section
The next NAME to query for NAPTR, SRV, or A records
on the value of the flags field. As mentioned above, this
be compressed
Substitution Expression Grammar
================================
The content of the regexp field is a substitution expression.
sed(1) substitution expressions are not appropriate for use in
application for a variety of reasons, therefore the contents of
regexp field MUST follow the grammar below
subst_expr = delim-char ere delim-char repl delim-char *
delim-char = "/" / "!" / ... (Any non-digit or non-flag character
than backslash '\'. All occurances of a delim_char in
subst_expr must be the same character.)
ere = POSIX Extended Regular Expression (see [13],
2.8.4)
repl = dns_str / backref / repl dns_str / repl
dns_str = 1*DNS_
backref = "\" 1POS_
Daniel & Mealling Experimental [Page 13]
RFC 2168 Resolution of URIs Using the DNS June 1997
flags = "i
DNS_CHAR = "-" / "0" / ... / "9" / "a" / ... / "z" / "A" / ... / "Z
POS_DIGIT = "1" / "2" / ... / "9" ; 0 is not an allowed
value domain name (see RFC-1123 [14]).
The result of applying the substitution expression to the
URI MUST result in a string that obeys the syntax for DNS host
[14]. Since it is possible for the regexp field to be
specified, such that a non-conforming host name can be constructed
client software SHOULD verify that the result is a legal host
before making queries on it
Backref expressions in the repl portion of the
expression are replaced by the (possibly empty) string of
enclosed by '(' and ')' in the ERE portion of the
expression. N is a single digit from 1 through 9, inclusive.
specifies the N'th backref expression, the one that begins with
N'th '(' and continues to the matching ')'. For example, the
(A(B(C)DE)(F)G
has backref expressions
\1 =
\2 =
\3 =
\4 =
\5..\9 = error - no matching
The "i" flag indicates that the ERE matching SHALL be performed in
case-insensitive fashion. Furthermore, any backref replacements
be normalized to lower case when the "i" flag is given
The first character in the substitution expression shall be used
the character that delimits the components of the
expression. There must be exactly three non-escaped occurrences
the delimiter character in a substitution expression. Since
occurrences of the delimiter character will be interpreted
occurrences of that character, digits MUST NOT be used as delimiters
Backrefs would be confused with literal digits were this allowed
Similarly, if flags are specified in the substitution expression,
delimiter character must not also be a flag character
Daniel & Mealling Experimental [Page 14]
RFC 2168 Resolution of URIs Using the DNS June 1997
Advice to domain administrators
================================
Beware of regular expressions. Not only are they a pain to
correct on their own, but there is the previously
interaction with DNS. Any backslashes in a regexp must be
twice in a zone file in order to appear once in a query response
More seriously, the need for double backslashes has probably not
tested by all implementors of DNS servers. We anticipate that urn.
will be the heaviest user of regexps. Only when delegating
of namespaces should the typical domain administrator need to
regexps
On a related note, beware of interactions with the shell
manipulating regexps from the command line. Since '\' is a
escape character in shells, there is a good chance that when
think you are saying "\\" you are actually saying "\".
caveats apply to characters such
The "a" flag allows the next lookup to be for A records rather
SRV records. Since there is no place for a port specification in
NAPTR record, when the "A" flag is used the specified protocol
be running on its default port
The URN Sytnax draft defines a canonical form for each URN,
requires %encoding characters outside a limited repertoire.
regular expressions MUST be written to operate on that
form. Since international character sets will end up with
use of %encoded characters, regular expressions operating on
will be essentially impossible to read or write by hand
=====
For the edification of implementers, pseudocode for a client
using NAPTRs is given below. This code is provided merely as
convience, it does not have any weight as a standard way to
NAPTR records. Also, as is the case with pseudocode, it has
been executed and may contain logical errors. You have been warned
//
// findResolver(URN
// Given a URN, find a host that can resolve it
//
findResolver(string URN) {
// prepend prefix to urn.
sprintf(key, "%s.urn.net", extractNS(URN));
do {
Daniel & Mealling Experimental [Page 15]
RFC 2168 Resolution of URIs Using the DNS June 1997
rewrite_flag = false
terminal = false
if (key has been seen) {
quit with a loop detected
}
add key to list of "seens
records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key
discard any records with an unknown value in the "flags" field
sort NAPTR records by "order" field and "preference"
(with "order" being more significant than "preference").
n_naptrs = number of NAPTR records in response
curr_order = records[0].order
max_order = records[n_naptrs-1].order
// Process current batch of NAPTRs according to "order" field
for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
if (unknown_flag) // skip this record and go to next
continue
newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
if (!newkey) // Skip to next record if the rewrite didn'
match continue
// We did do a rewrite, shrink max_order to current
// so that delegation works
max_order = naptr[j].order
// Will we know what to do with the protocol and
// specified in the NAPTR? If not, try next record
if(!isKnownProto(naptr[j].services)) {
continue
}
if(!isKnownService(naptr[j].services)) {
continue
}
// At this point we have a successful rewrite and we
// know how to speak the protocol and request a
// resolution service. Before we do the next lookup,
// some optimization possibilities
if (strcasecmp(flags, "S")
|| strcasecmp(flags, "P"))
|| strcasecmp(flags, "A")) {
terminal = true
services = naptr[j].services
addnl = any SRV and/or A records returned as
info for naptr[j].
}
key = newkey
Daniel & Mealling Experimental [Page 16]
RFC 2168 Resolution of URIs Using the DNS June 1997
rewriteflag = true
break
}
} while (rewriteflag && !terminal);
// Did we not find our way to a resolver
if (!rewrite_flag) {
report an
return NULL
}
// Leave rest to another protocol
if (strcasecmp(flags, "P")) {
return key as host to talk to
}
// If not, keep
if (!addnl) { // No SRVs came in as additional info, look them
srvs = lookup(type=SRV, key);
}
sort SRV records by preference, weight, ...
foreach (SRV record) { // in order of
try contacting srv[j].target using the protocol and one of
resolution service requests from the "services" field of
last NAPTR record
if (successful
return (target, protocol, service);
// Actually we would probably return a result, but
// code was supposed to just tell us a good host to talk to
}
die with an "unable to find a host" error
}
Notes
======
- A client MUST process multiple NAPTR records in the
specified by the "order" field, it MUST NOT simply use the
record that provides a known protocol and service combination
Daniel & Mealling Experimental [Page 17]
RFC 2168 Resolution of URIs Using the DNS June 1997
- If a record at a particular order matches the URI, but
client doesn't know the specified protocol and service,
client SHOULD continue to examine records that have the
order. The client MUST NOT consider records with a higher
of order. This is necessary to make delegation of portions
the namespace work. The order field is what lets
administrators say "all requests for URIs matching pattern x
to server 1, all others go to server 2".
(A match is defined as
1) The NAPTR provides a replacement domain
2) The regular expression matches the
)
- When multiple RRs have the same "order", the client should
the value of the preference field to select the next NAPTR
consider. However, because of preferred protocols or services
estimates of network distance and bandwidth, etc. clients
use different criteria to sort the records
- If the lookup after a rewrite fails, clients are
encouraged to report a failure, rather than backing up to
other rewrite paths
- When a namespace is to be delegated among a set of resolvers
regexps must be used. Each regexp appears in a separate
RR. Administrators should do as little delegation as possible
because of limitations on the size of DNS responses
- Note that SRV RRs impose additional requirements on clients
Acknowledgments
=================
The editors would like to thank Keith Moore for all his
during the development of this draft. We would also like to
Paul Vixie for his assistance in debugging our implementation,
his answers on our questions. Finally, we would like to
our enormous intellectual debt to the participants in the
series of meetings, as well as to the participants in the URI and
working groups
References
===========
[1] Sollins, Karen and Larry Masinter, "Functional
for Uniform Resource Names", RFC-1737, Dec. 1994.
[2] The URN Implementors, Uniform Resource Names: A Progress Report
http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine
February 1996.
Daniel & Mealling Experimental [Page 18]
RFC 2168 Resolution of URIs Using the DNS June 1997
[3] Moats, Ryan, "URN Syntax", RFC-2141, May 1997.
[4] Gulbrandsen, A. and P. Vixie, "A DNS RR for
the location of services (DNS SRV)", RFC-2052, October 1996.
[5] Daniel, Jr., Ron, "A Trivial Convention for using HTTP in
Resolution", RFC-2169, June 1997.
[6] URN-WG, "URN Resolution Services", Work in Progress
[7] Moore, Keith, Shirley Browne, Jason Cox, and Jonathan Gettler
Resource Cataloging and Distribution System, Technical
CS-97-346, University of Tennessee, Knoxville, December 1996
[8] Paul Vixie, personal communication
[9] Crocker, Dave H. "Standard for the Format of ARPA Internet
Messages", RFC-822, August 1982.
[10] Orth, Charles and Bill Arms; Handle Resolution
Specification, http://www.handle.net/docs/client_spec.
[11] Williamson, S., M. Kosters, D. Blacka, J. Singh, K. Zeilstra
"Referral Whois Protocol (RWhois)", RFC-2167, June 1997.
[12] Information Retrieval (Z39.50): Application Service
and Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.
[13] IEEE Standard for Information Technology - Portable
System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
IEEE Std 1003.2-1992; The Institute of Electrical
Electronics Engineers; New York; 1993. ISBN:1-55937-255-9
[14] Braden, R., "Requirements for Internet Hosts - Application
and Support", RFC-1123, Oct. 1989.
[15] Sollins, Karen, "Requirements and a Framework for URN
Systems", November 1996, Work in Progress
Daniel & Mealling Experimental [Page 19]
RFC 2168 Resolution of URIs Using the DNS June 1997
Security
=======================
The use of "urn.net" as the registry for URN namespaces is subject
denial of service attacks, as well as other DNS spoofing attacks.
interactions with DNSSEC are currently being studied. It is
that NAPTR records will be signed with SIG records once the
work is deployed
The rewrite rules make identifiers from other namespaces subject
the same attacks as normal domain names. Since they have not
easily resolvable before, this may or may not be considered
problem
Regular expressions should be checked for sanity, not blindly
to something like PERL
This document has discussed a way of locating a resolver, but has
discussed any detail of how the communication with the resolver
place. There are significant security considerations attached to
communication with a resolver. Those considerations are outside
scope of this document, and must be addressed by the
for particular resolver communication protocols
Author Contact Information
===========================
Ron
Los Alamos National
MS B287
Los Alamos, NM, USA, 87545
voice: +1 505 665 0597
fax: +1 505 665 4939
email: rdaniel@lanl.
Michael
Network
505 Huntmar Park
Herndon, VA 22070
voice: (703) 742-0400
fax: (703) 742-9552
email: michaelm@internic.
URL: http://www.netsol.com
Daniel & Mealling Experimental [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
