draft-ietf-urn-dns-ddds-database-06.txt   draft-ietf-urn-dns-ddds-database-07.txt 
Network Working Group M. Mealling Network Working Group M. Mealling
Internet-Draft VeriSign Internet-Draft VeriSign
Expires: February 26, 2002 August 28, 2001 Expires: April 28, 2002 October 28, 2001
A DDDS Database Using The Domain Name System Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
draft-ietf-urn-dns-ddds-database-06 Database
draft-ietf-urn-dns-ddds-database-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 26, 2002. This Internet-Draft will expire on April 28, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document describes a Dynamic Delegation Discovery System This document describes a Dynamic Delegation Discovery System
Database using the Domain Name System as a distributed database of Database using the Domain Name System as a distributed database of
Rules. The Keys are domain-names and the Rules are encoded using the Rules. The Keys are domain-names and the Rules are encoded using the
NAPTR Resource Record. NAPTR Resource Record.
Since this document officially obsoletes RFC 2915, it is the official Since this document obsoletes RFC 2915, it is the official
specification for the NAPTR DNS Resource Record. specification for the NAPTR DNS Resource Record. It is also part of
a series that is completely specified in "Dynamic Delegation
Discovery System (DDDS) Part One: The Comprehensive DDDS Standard"
(RFC WWWW). It is very important to note that it is impossible to
read and understand any document in this series without reading the
others.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DDDS Database Specification . . . . . . . . . . . . . . . . 5 3. DDDS Database Specification . . . . . . . . . . . . . . . . 5
4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 7 4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Additional Information Processing . . . . . . . . . . . . . 9 4.2 Additional Information Processing . . . . . . . . . . . . . 9
4.2.1 Additional Section processing by DNS servers . . . . . . . . 9 4.2.1 Additional Section processing by DNS servers . . . . . . . . 9
skipping to change at page 3, line 7 skipping to change at page 3, line 7
7. Advice for DNS Administrators . . . . . . . . . . . . . . . 14 7. Advice for DNS Administrators . . . . . . . . . . . . . . . 14
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The NAPTR DNS Resource Record was originally produced by the URN The Dynamic Delegation Discovery System is used to implement lazy
Working Group as a way to encode rule-sets in DNS so that the binding of strings to data, in order to support dynamically
delegated sections of a URI could be decomposed in such a way that configured delegation systems. The DDDS functions by mapping some
they could be changed and re-delegated over time. The result was a unique string to data stored within a DDDS Database by iteratively
Resource Record that included a regular expression that would be used applying string transformation rules until a terminal condition is
by a client program to rewrite a string into a domain name. Regular reached.
expressions were chosen for their compactness to expressivity ratio
allowing for a great deal of information to be encoded in a rather This document describes the way in which the Domain Name System is
small DNS packet. used as a data store for the Rules that allow a DDDS Application to
function. It does not specify any particular application or usage
scenario. The entire series of documents is specified in "Dynamic
Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS
Standard" (RFC WWWW) [1]. It is very important to note that it is
impossible to read and understand any document in that series without
reading the related documents.
The NAPTR DNS Resource Record specified here was originally produced
by the URN Working Group as a way to encode rule-sets in DNS so that
the delegated sections of a URI could be decomposed in such a way
that they could be changed and re-delegated over time. The result
was a Resource Record that included a regular expression that would
be used by a client program to rewrite a string into a domain name.
Regular expressions were chosen for their compactness to expressivity
ratio allowing for a great deal of information to be encoded in a
rather small DNS packet.
Over time this process was generalized for other Applications and Over time this process was generalized for other Applications and
Rule Databases. This document defines a Rules Database absent any Rule Databases. This document defines a Rules Database absent any
particular Application as there may be several Applications all particular Application as there may be several Applications all
taking advantage of this particular Rules Database. taking advantage of this particular Rules Database.
As a result of this generalization, this document, along with RFC
ZZZZ [11] and RFC XXXX [12], obsoletes RFC 2168 [14], RFC 2915 [13]
and updates RFC 2276 [10].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [6].
All other terminology, especially capitalized terms, is taken from All other terminology, especially capitalized terms, is taken from
[11]. [3].
3. DDDS Database Specification 3. DDDS Database Specification
General Description: General Description:
This database uses the Domain Name System (DNS) as specified in This database uses the Domain Name System (DNS) as specified in
[3] and [2]. [8] and [7].
The character set used to specify the various values of the NAPTR The character set used to specify the various values of the NAPTR
records is UTF-8 [15]. Care must be taken to ensure that, in the records is UTF-8 [17]. Care must be taken to ensure that, in the
case where either the input or the output to the substitution case where either the input or the output to the substitution
expression contains code points outside of the ASCII/Unicode expression contains code points outside of the ASCII/Unicode
equivalence in UTF-8, any UTF-8 is interpreted as a series of equivalence in UTF-8, any UTF-8 is interpreted as a series of
code-points instead of as a series of bytes. This is to ensure code-points instead of as a series of bytes. This is to ensure
that the internationalized features of the POSIX Extended Regular that the internationalized features of the POSIX Extended Regular
Expressions are able to match their intended code-points. Expressions are able to match their intended code-points.
Substitution expressions MUST NOT be written where they depend on Substitution expressions MUST NOT be written where they depend on
a specific POSIX locale since this would cause substutition a specific POSIX locale since this would cause substutition
expressions to loose their ability to be universally applicable. expressions to loose their ability to be universally applicable.
skipping to change at page 5, line 43 skipping to change at page 5, line 43
series of NAPTR records. The format of a NAPTR Resource Record series of NAPTR records. The format of a NAPTR Resource Record
can be found in Section 4. can be found in Section 4.
Rule Insertion Procedure: Rule Insertion Procedure:
Rules are inserted by adding new records to the appropriate DNS Rules are inserted by adding new records to the appropriate DNS
zone. If a Rule produces a Key that exists in a particular zone zone. If a Rule produces a Key that exists in a particular zone
then only the entity that has administrative control of that zone then only the entity that has administrative control of that zone
can specify the Rule associated with that Key. can specify the Rule associated with that Key.
Collision Avoidance: Collision Avoidance:
In the case where two Application may use this Database (which is In the case where two Applications may use this Database (which is
actually the case with the ENUM and URI Resolution Applications), actually the case with the ENUM and URI Resolution Applications),
there is a chance of collision between rules where two NAPTR there is a chance of collision between rules where two NAPTR
records appear in the same domain but they apply to more than one records appear in the same domain but they apply to more than one
Appliation. There are three ways to avoid collisions: Appliation. There are three ways to avoid collisions:
* create a new zone within the domain in common that contains * create a new zone within the domain in common that contains
only NAPTR records that are appropriate for the application. only NAPTR records that are appropriate for the application.
E.g., all URI Resolution records would exist under E.g., all URI Resolution records would exist under
urires.example.com and all ENUM records would be under urires.example.com and all ENUM records would be under
enum.example.com. In the case where this is not possible due enum.example.com. In the case where this is not possible due
skipping to change at page 7, line 31 skipping to change at page 7, line 31
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ SERVICES / / SERVICES /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REGEXP / / REGEXP /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REPLACEMENT / / REPLACEMENT /
/ / / /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
<character-string> and <domain-name> as used here are defined in <character-string> and <domain-name> as used here are defined in
RFC1035 [2]. RFC1035 [7].
ORDER ORDER
A 16-bit unsigned integer specifying the order in which the NAPTR A 16-bit unsigned integer specifying the order in which the NAPTR
records MUST be processed in order to accurately represent the records MUST be processed in order to accurately represent the
ordered list of Rules. The ordering is from lowest to highest. ordered list of Rules. The ordering is from lowest to highest.
If two records have the same order value then they are considered If two records have the same order value then they are considered
to be the same rule and should be selected randomly unless the to be the same rule and should be selected randomly unless the
Preference numbers are different which means the randomization is Preference numbers are different which means the randomization is
weighted according to the ratio of the Preference values. weighted according to the ratio of the Preference values.
skipping to change at page 8, line 17 skipping to change at page 8, line 17
The important difference between Order and Preference is that once The important difference between Order and Preference is that once
a match is found the client MUST NOT consider records with a a match is found the client MUST NOT consider records with a
different Order but they MAY process records with the same Order different Order but they MAY process records with the same Order
but different Preferences. I.e. Preference is used to give but different Preferences. I.e. Preference is used to give
weight to rules that are considered the same from an authority weight to rules that are considered the same from an authority
standpoint but not from a simple load balancing standpoint. standpoint but not from a simple load balancing standpoint.
FLAGS FLAGS
A <character-string> containing flags to control aspects of the A <character-string> containing flags to control aspects of the
rewriting and interpretation of the fields in the record. Flags rewriting and interpretation of the fields in the record. Flags
are single characters from the set [A-Z0-9]. The case of the are single characters from the set A-Z and 0-9. The case of the
alphabetic characters is not significant. alphabetic characters is not significant. The field can be empty.
It is up to the Application specifying how it is using this It is up to the Application specifying how it is using this
Database to define the Flags in this field. It must define which Database to define the Flags in this field. It must define which
ones are terminal and which ones are not. ones are terminal and which ones are not.
SERVICES SERVICES
A <character-string> that specifies the Service Parameters A <character-string> that specifies the Service Parameters
applicable to this this delegation path. It is up to the applicable to this this delegation path. It is up to the
Application Specification to specify the values found in this Application Specification to specify the values found in this
field. field.
skipping to change at page 9, line 31 skipping to change at page 9, line 31
Applications MAY inspect the Additional Information section for Applications MAY inspect the Additional Information section for
relevant records but Applications MUST NOT require that records of relevant records but Applications MUST NOT require that records of
any type be in the Additional Information section of any DNS response any type be in the Additional Information section of any DNS response
in order for clients to function. All Applications must be capable in order for clients to function. All Applications must be capable
of handling responses from nameservers that never fill in the of handling responses from nameservers that never fill in the
Additional Information part of a response. Additional Information part of a response.
4.3 Master File Format 4.3 Master File Format
The master file format follows the standard rules in RFC-1035[1]. The master file format follows the standard rules in RFC-1035. Order
Order and preference, being 16-bit unsigned integers, shall be an and preference, being 16-bit unsigned integers, shall be an integer
integer between 0 and 65535. The Flags and Services and Regexp between 0 and 65535. The Flags and Services and Regexp fields are
fields are all quoted <character-string>s. Since the Regexp field all quoted <character-string>s. Since the Regexp field can contain
can contain numerous backslashes and thus should be treated with numerous backslashes and thus should be treated with care. See
care. See Section 10 for how to correctly enter and escape the Section 10 for how to correctly enter and escape the regular
regular expression. expression.
5. Application Specifications 5. Application Specifications
This DDDS Database is usable by any application that makes use of the This DDDS Database is usable by any application that makes use of the
DDDS algorithm. In addition to the items required to specify a DDDS DDDS algorithm. In addition to the items required to specify a DDDS
Application, an application wishing to use this Database must also Application, an application wishing to use this Database must also
define the following values: define the following values:
o What domain the Key that is produced by the First Well Known Rule o What domain the Key that is produced by the First Well Known Rule
belongs to. Any application must ensure that its rules do not belongs to. Any application must ensure that its rules do not
collide with rules used by another application making use of this collide with rules used by another application making use of this
Database. For example, the 'foo' application might have all of Database. For example, the 'foo' application might have all of
its First Well Known Keys be found in the 'foo.net' zone. its First Well Known Keys be found in the 'foo.net' zone.
o What the allowed values for the Services and Protocols fields are. o What the allowed values for the Services and Protocols fields are.
o What the expected output is of the terminal rewrite rule o What the expected output is of the terminal rewrite rule in
addition to how the Flags are actually encoded and utilized.
6. Examples 6. Examples
6.1 URN Example 6.1 URN Example
The NAPTR record was originally created for use with the Uniform The NAPTR record was originally created for use with the Uniform
Resource Name Resolver Discovery System. This example details how a Resource Name Resolver Discovery System. This example details how a
particular URN would use the NAPTR record to find a resolver service particular URN would use the NAPTR record to find a resolver service
that can answer questions about the URN. See [12] for the definitive that can answer questions about the URN. See [2] for the definitive
specification for this Application. specification for this Application.
Consider a URN namespace based on MIME Content-Ids (this is very Consider a URN namespace based on MIME Content-Ids (this is very
hypothetical so do not rely on this). The URN might look like this: hypothetical so do not rely on this). The URN might look like this:
urn:cid:199606121851.1@bar.example.com urn:cid:199606121851.1@bar.example.com
This Application's First Well Known Rule is to extract the characters This Application's First Well Known Rule is to extract the characters
between the first and second colon. For this URN that would be between the first and second colon. For this URN that would be
'cid'. The Application also specifies that, in order to build a 'cid'. The Application also specifies that, in order to build a
skipping to change at page 13, line 6 skipping to change at page 13, line 6
for this Database, periods are inserted between each digit, the for this Database, periods are inserted between each digit, the
entire Key is inverted and then "e164.arpa" is appended to the end. entire Key is inverted and then "e164.arpa" is appended to the end.
The above telephone number would then read The above telephone number would then read
"2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to
retrieve Rewrite Rules as NAPTR records. retrieve Rewrite Rules as NAPTR records.
For this example telephone number we might get back the following For this example telephone number we might get back the following
NAPTR records: NAPTR records:
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
IN NAPTR 100 10 "u" "sip+N2R" "!^.*$!sip:information@foo.se!" . IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" .
IN NAPTR 102 10 "u" "smtp+N2R" "!^.*$!mailto:information@foo.se!" . IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .
ENUM uses the same 'u' flag as the URI Resolution Application. This ENUM uses the same 'u' flag as the URI Resolution Application. This
flag states that the Rule is terminal and that the output is a URL flag states that the Rule is terminal and that the output is a URL
which contains the information needed to contact that telephone which contains the information needed to contact that telephone
service. ENUM also uses the same format for its Service Parameters. service. ENUM also uses the same format for its Service Parameters.
These state that the available protocols used to access that These state that the available protocols used to access that
telephone's service are either the Session Initiation Protocol or telephone's service are either the Session Initiation Protocol or
SMTP mail. SMTP mail.
7. Advice for DNS Administrators 7. Advice for DNS Administrators
skipping to change at page 18, line 7 skipping to change at page 18, line 7
This Database makes identifiers from other namespaces subject to the This Database makes identifiers from other namespaces subject to the
same attacks as normal domain names. Since they have not been easily same attacks as normal domain names. Since they have not been easily
resolvable before, this may or may not be considered a problem. resolvable before, this may or may not be considered a problem.
Regular expressions should be checked for sanity, not blindly passed Regular expressions should be checked for sanity, not blindly passed
to something like PERL since arbitrary code can be included and to something like PERL since arbitrary code can be included and
subsequently processed. subsequently processed.
References References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-
urn-ddds-toc-00.txt (work in progress), October 2001.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work
in progress), May 2000.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-
database-07.txt (work in progress), May 2000.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The URI Resolution Application", RFC YYYY, draft-ietf-
urn-uri-res-ddds-05.txt (work in progress), October 2000.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-
urn-net-procedures-09.txt (work in progress), October 2001.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] Mockapetris, P., "Domain names - implementation and [7] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, STD 13, Nov 1987. specification", RFC 1035, STD 13, Nov 1987.
[3] Mockapetris, P., "Domain names - concepts and facilities", RFC [8] Mockapetris, P., "Domain names - concepts and facilities", RFC
1034, STD 13, Nov 1987. 1034, STD 13, Nov 1987.
[4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", [10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
RFC 2234, November 1997. RFC 2234, November 1997.
[6] Daniel, R., "A Trivial Convention for using HTTP in URN [11] Daniel, R., "A Trivial Convention for using HTTP in URN
Resolution", RFC 2169, June 1997. Resolution", RFC 2169, June 1997.
[7] IEEE, "IEEE Standard for Information Technology - Portable [12] IEEE, "IEEE Standard for Information Technology - Portable
Operating System Interface (POSIX) - Part 2: Shell and Operating System Interface (POSIX) - Part 2: Shell and
Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993. Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
[9] Moats, R., "URN Syntax", RFC 2141, May 1997. [14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[10] Sollins, K., "Architectural Principles of Uniform Resource Name [15] Sollins, K., "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998. Resolution", RFC 2276, January 1998.
[11] Mealling, M., "Dynamic Delegation Discovery System (DDDS)", RFC [16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
ZZZZ, draft-ietf-urn-ddds-00.txt (work in progress), May 2000.
[12] Mealling, M., "URI Resolution using the Dynamic Delegation
Discovery System", RFC XXXX, draft-ietf-urn-uri-res-ddds-00.txt
(work in progress), July 2000.
[13] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, August 2000.
[14] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC 2168, June 1997. Identifiers using the Domain Name System", RFC 2168, June 1997.
[15] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
Author's Address Author's Address
Michael Mealling Michael Mealling
VeriSign VeriSign
505 Huntmar Park Drive 505 Huntmar Park Drive
Herndon, VA 22070 Herndon, VA 22070
US US
 End of changes. 29 change blocks. 
60 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/