Another interesting and barely used dns type is NAPTR. It is called
"Naming Authority Pointer DNS Resource Record" and this is a standard
track RFC and not expirimental one. The record has multiple uses and can
be used to specify URN for particual service, but it seems from the text
various other uses for this record would be welcome. The record allows for
much flexibility with its support for regular expressions syntax. This
record may prove very usefull for dealing with wildcards and possibly
directly for MARID records in general.
I recommend you read the RFC in full - http://www.faqs.org/rfcs/rfc2915.html
And below are some of the text from that RFC:
4. The Basic NAPTR Algorithm
The behavior and meaning of the flags and services assume an
algorithm where the output of one rewrite is a new key that points to
another rule. This looping algorithm allows NAPTR records to
incrementally specify a complete rule. These incremental rules can
be delegated which allows other entities to specify rules so that one
entity does not need to understand _all_ rules.
The algorithm starts with a string and some known key (domain).
NAPTR records for this key are retrieved, those with unknown Flags or
inappropriate Services are discarded and the remaining records are
sorted by their Order field. Within each value of Order, the records
are further sorted by the Preferences field.
The records are examined in sorted order until a matching record is
found. A record is considered a match iff:
o it has a Replacement field value instead of a Regexp field value.
o or the Regexp field matches the string held by the client.
The first match MUST be the match that is used. Once a match is
found, the Services field is examined for whether or not this rule
advances toward the desired result. If so, the rule is applied to
the target string. If not, the process halts. The domain that
results from the regular expression is then used as the domain of the
next loop through the NAPTR algorithm. Note that the same target
string is used throughout the algorithm.
This looping is extremely important since it is the method by which
complex rules are broken down into manageable delegated chunks. The
flags fields simply determine at which point the looping should stop
(or other specialized behavior).
Since flags are valid at any level of the algorithm, the degenerative
case is to never loop but to look up the NAPTR and then stop. In
many specialized cases this is all that is needed. Implementors
should be aware that the degenerative case should not become the
common case.
5. Concerning How NAPTR Uses SRV Records
When the SRV record type was originally specified it assumed that the
client did not know the specific domain-name before hand. The client
would construct a domain-name more in the form of a question than the
usual case of knowing ahead of time that the domain-name should
exist. I.e., if the client wants to know if there is a TCP based
HTTP server running at a particular domain, the client would
construct the domain-name _http._tcp.somedomain.com and ask the DNS
if that records exists. The underscores are used to avoid collisions
with potentially 'real' domain-names.
In the case of NAPTR, the actual domain-name is specified by the
various fields in the NAPTR record. In this case the client isn't
asking a question but is instead attempting to get at information
that it has been told exists in an SRV record at that particular
domain-name. While this usage of SRV is slightly different than the
SRV authors originally intended it does not break any of the
assumptions concerning what SRV contains. Also, since the NAPTR
explicitly spells out the domain-name for which an SRV exists, that
domain-name MUST be used in SRV queries with NO transformations. Any
given NAPTR record may result in a domain-name to be used for SRV
queries that may or may not contain the SRV standardized underscore
characters. NAPTR applications that make use of SRV MUST NOT attempt
to understand these domains or use them according to how the SRV
specification structures its query domains.
6. Application Specifications
It should be noted that the NAPTR algorithm is the basic assumption
about how NAPTR works. The reasons for the rewrite and the expected
output and its use are specified by documents that define what
applications the NAPTR record and algorithm are used for. Any
document that defines such an application must define the following:
o The first known domain-name or how to build it
o The valid Services and Protocols
o What the expected use is for the output of the last rewrite
o The validity and/or behavior of any 'P' flag protocols.
o The general semantics surrounding why and how NAPTR and its
algorithm are being used.
7. Examples
NOTE: These are examples only. They are taken from ongoing work and
may not represent the end result of that work. They are here for
pedagogical reasons only.
7.1 Example 1
NAPTR was originally specified for use with the a Uniform Resource
Name Resolver Discovery System. This example details how a
particular URN would use the NAPTR record to find a resolver service.
Consider a URN namespace based on MIME Content-Ids. The URN might
look like this:
urn:cid:39CB83F7.A8450130@fake.gatech.edu
(Note that this example is chosen for pedagogical purposes, and does
not conform to the CID URL scheme.)
The first step in the resolution process is to find out about the CID
namespace. The namespace identifier [3], 'cid', is extracted from
the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first
'known' key in the NAPTR algorithm. The NAPTR records for
cid.urn.arpa looked up and return a single record:
cid.urn.arpa.
;; order pref flags service regexp replacement
IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" .
There is only one NAPTR response, so ordering the responses is not a
problem. The replacement field is empty, so the pattern provided in
the regexp field is used. We apply that regexp to the entire URN to
see if it matches, which it does. The \2 part of the substitution
expression returns the string "gatech.edu". Since the flags field
does not contain "s" or "a", the lookup is not terminal and our next
probe to DNS is for more NAPTR records where the new domain is '
gatech.edu' and the string is the same string as before.
Note that the rule does not extract the full domain name from the
CID, instead it assumes the CID comes from a host and extracts its
domain. While all hosts, such as mordred, could have their very own
NAPTR, maintaining those records for all the machines at a site as
large as Georgia Tech would be an intolerable burden. Wildcards are
not appropriate here since they only return results when there is no
exactly matching names already in the system.
The record returned from the query on "gatech.edu" might look like:
;; order pref flags service regexp replacement
IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu.
IN NAPTR 100 50 "s" "rcds+I2C" "" _rcds._udp.gatech.edu.
IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu.
Continuing with the example, note that the values of the order and
preference fields are equal in all records, so the client is free to
pick any record. The flags field tells us that these are the last
NAPTR patterns we should see, and after the rewrite (a simple
replacement in this case) we should look up SRV records to get
information on the hosts that can provide the necessary service.
Assuming we prefer the Z39.50 protocol, our lookup might return:
;; Pref Weight Port Target
_z3950._tcp.gatech.edu. IN SRV 0 0 1000 z3950.gatech.edu.
IN SRV 0 0 1000 z3950.cc.gatech.edu.
IN SRV 0 0 1000 z3950.uga.edu.
telling us three hosts that could actually do the resolution, and
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 name
from the CID, and \. for matching the literal '.' characters
separating the domain name components. Since '\' is the escape
character, literal occurances of a backslash must be escaped by
another backslash. For the case of the cid.urn.arpa record above,
the regular expression entered into the master file should be
"/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually
receives the record, the pattern will have been converted to
"/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
7.2 Example 2
Even if URN systems were in place now, there would still be a
tremendous number of URLs. It should be possible to develop a URN
resolution system that can also provide location independence for
those URLs. This is related to the requirement that URNs be able to
grandfather in names from other naming systems, such as ISO Formal
Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
etc.
The NAPTR RR could also be used for URLs that have already been
assigned. Assume we have the URL for a very popular piece of
software that the publisher wishes to mirror at multiple sites around
the world:
Using the rules specified for this application we extract the prefix,
"http", and lookup NAPTR records for http.uri.arpa. This might
return a record of the form
http.uri.arpa. IN NAPTR
;; order pref flags service regexp replacement
100 90 "" "" "!http://([^/:]+)!\1!i" .
This expression returns everything after the first double slash and
before the next slash or colon. (We use the '!' character to delimit
the parts of the substitution expression. Otherwise we would have to
use backslashes to escape the forward slashes and would have a regexp
in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
Applying this pattern to the URL extracts "www.foo.com". Looking up
NAPTR records for that might return:
www.foo.com.
;; order pref flags service regexp replacement
IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com.
IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com.
Looking up SRV records for http.tcp.foo.com would return information
on the hosts that foo.com has designated to be its mirror sites. The
client can then pick one for the user.
7.3 Example 3
A non-URI example is the ENUM application which uses a NAPTR record
to map an e.164 telephone number to a URI. In order to convert the
phone number to a domain name for the first iteration all characters
other than digits are removed from the the telephone number, the
entire number is inverted, periods are put between each digit and the
string ".e164.arpa" is put on the left-hand side. For example, the
E.164 phone number "+1-770-555-1212" converted to a domain-name it
would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
For this example telephone number we might get back the following
NAPTR records:
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information(_at_)tele2(_dot_)se!"
.
IN NAPTR 102 10 "u" "mailto+E2U"
"!^.*$!mailto:information(_at_)tele2(_dot_)se!" .
This application uses the same 'u' flag as the URI Resolution
application. This flag states that the Rule is terminal and that the
output is a URI which contains the information needed to contact that
telephone service. ENUM also uses the same format for its Service
field except that it defines the 'E2U' service instead of the 'I2*'
services that URI resolution uses. The example above states that the
available protocols used to access that telephone's service are
either the Session Initiation Protocol or SMTP mail.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net