draft-ietf-urn-dns-ddds-database-07.txt   draft-ietf-urn-dns-ddds-database-08.txt 
Network Working Group M. Mealling Network Working Group M. Mealling
Internet-Draft VeriSign Internet-Draft VeriSign
Expires: April 28, 2002 October 28, 2001 Expires: August 20, 2002 February 19, 2002
Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
Database Database
draft-ietf-urn-dns-ddds-database-07.txt draft-ietf-urn-dns-ddds-database-08.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 32 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 April 28, 2002. This Internet-Draft will expire on August 20, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). 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 obsoletes RFC 2915, it is the official Since this document obsoletes RFC 2915, it is the official
specification for the NAPTR DNS Resource Record. It is also part of specification for the NAPTR DNS Resource Record. It is also part of
skipping to change at page 5, line 44 skipping to change at page 5, line 44
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 Applications 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 Section 6.2), there is a chance of collision between rules where
records appear in the same domain but they apply to more than one two NAPTR records appear in the same domain but they apply to more
Appliation. There are three ways to avoid collisions: than one 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
to lack of control over the upstream delegation the second to lack of control over the upstream delegation the second
method is used. method is used.
* write the regular expression such that it contains enough of * write the regular expression such that it contains enough of
skipping to change at page 7, line 38 skipping to change at page 7, line 38
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
<character-string> and <domain-name> as used here are defined in <character-string> and <domain-name> as used here are defined in
RFC1035 [7]. 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 based on the
Preference numbers are different which means the randomization is combination of the Preference values and Services offered.
weighted according to the ratio of the Preference values.
PREFERENCE PREFERENCE
Although it is called "preference" in deference to DNS Although it is called "preference" in deference to DNS
terminology, this field is equivalent to the Priority value in the terminology, this field is equivalent to the Priority value in the
DDDS Algorithm. It is a 16-bit unsigned integer that specifies DDDS Algorithm. It is a 16-bit unsigned integer that specifies
the order in which NAPTR records with equal Order values SHOULD be the order in which NAPTR records with equal Order values SHOULD be
processed, low numbers being processed before high numbers. This processed, low numbers being processed before high numbers. This
is similar to the preference field in an MX record, and is used so is similar to the preference field in an MX record, and is used so
domain administrators can direct clients towards more capable domain administrators can direct clients towards more capable
hosts or lighter weight protocols. A client MAY look at records hosts or lighter weight protocols. A client MAY look at records
with higher preference values if it has a good reason to do so with higher preference values if it has a good reason to do so
such as not understanding some protocol or service. such as not supporting some protocol or service very well.
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. The only exception to this is noted in
weight to rules that are considered the same from an authority the second important Note in the DDDS algorithm specification
standpoint but not from a simple load balancing standpoint. concerning allowing clients to use more complex Service
determination between steps 3 and 4 in the algorithm. Preference
is used to give communicate a higher quality of service to rules
that are considered the same from an authority standpoint but not
from a simple load balancing standpoint.
It is important to note that DNS contains several load balancing
mechanisms and if load balancing among otherwise equal services
should be needed then methods such as SRV records or multiple A
records should be utilized to accomplish load balancing.
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-Z and 0-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. The field can be empty. 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.
skipping to change at page 8, line 50 skipping to change at page 9, line 11
tempting in some applications but experience has shown such use to tempting in some applications but experience has shown such use to
be extremely fault sensitive, very error prone, and extremely be extremely fault sensitive, very error prone, and extremely
difficult to debug. difficult to debug.
REPLACEMENT REPLACEMENT
A <domain-name> which is the next domain-name to query for A <domain-name> which is the next domain-name to query for
depending on the potential values found in the flags field. This depending on the potential values found in the flags field. This
field is used when the regular expression is a simple replacement field is used when the regular expression is a simple replacement
operation. Any value in this field MUST be a fully qualified operation. Any value in this field MUST be a fully qualified
domain-name. Name compression is not to be used for this field. domain-name. Name compression is not to be used for this field.
This field and the REGEXP field together make up the Substitution This field and the REGEXP field together make up the Substitution
Expression in the DDDS Algorithm. They are also mutually Expression in the DDDS Algorithm. It is simply a historical
exclusive. If a record is returned that has values for both optimization specifically for DNS compression that this field
fields then it is considered to be in error and should be ignored. exists. The fields are also mutually exclusive. If a record is
returned that has values for both fields then it is considered to
be in error and SHOULD be either ignored or an error returned.
4.2 Additional Information Processing 4.2 Additional Information Processing
Additional section processing requires upgraded DNS servers, thus it Additional section processing requires upgraded DNS servers, thus it
will take many years before applications can expect to see relevant will take many years before applications can expect to see relevant
records in the additional information section. records in the additional information section.
4.2.1 Additional Section processing by DNS servers 4.2.1 Additional Section processing by DNS servers
DNS servers MAY add RRsets to the additional information section that DNS servers MAY add RRsets to the additional information section that
skipping to change at page 9, line 36 skipping to change at page 9, line 48
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. Order The master file format follows the standard rules in RFC-1035. Order
and preference, being 16-bit unsigned integers, shall be an integer and preference, being 16-bit unsigned integers, shall be an integer
between 0 and 65535. The Flags and Services and Regexp fields are between 0 and 65535. The Flags and Services and Regexp fields are
all quoted <character-string>s. Since the Regexp field can contain all quoted <character-string>s. Since the Regexp field can contain
numerous backslashes and thus should be treated with care. See numerous backslashes and thus should be treated with care. See
Section 10 for how to correctly enter and escape the regular Section 7 for how to correctly enter and escape the 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
skipping to change at page 12, line 34 skipping to change at page 12, line 34
character, literal occurances of a backslash must be escaped by character, literal occurances of a backslash must be escaped by
another backslash. For the case of the cid.urn.arpa record above, another backslash. For the case of the cid.urn.arpa record above,
the regular expression entered into the master file should be the regular expression entered into the master file should be
"!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually "!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually
receives the record, the pattern will have been converted to receives the record, the pattern will have been converted to
"!urn:cid:.+@([^\.]+\.)(.*)$!\2!i". "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i".
6.2 E164 Example 6.2 E164 Example
The ENUM Working Group in the IETF has specified a service that The ENUM Working Group in the IETF has specified a service that
allows a telephone number to be mapped to a URI. The Application allows a telephone number to be mapped to a URI [18]. The
Unique String for the ENUM Application is the E.164 telephone number Application Unique String for the ENUM Application is the E.164
with the dashes removed. The First Well Known Rule is to remove all telephone number with the dashes removed. The First Well Known Rule
characters from the the telephone number and then use the entire is to remove all characters from the the telephone number and then
number as the first Key. For example, the phone number "770-555- use the entire number as the first Key. For example, the phone
1212" represented as an E.164 number would be "+1-770-555-1212". number "770-555-1212" represented as an E.164 number would be "+1-
Converted to the Key it would be "17705551212". 770-555-1212". Converted to the Key it would be "17705551212".
The ENUM Application at present only uses this Database. It The ENUM Application at present only uses this Database. It
specifies that, in order to convert the first Key into a form valid specifies that, in order to convert the first Key into a form valid
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+E2U" "!^.*$!sip:information@foo.se!i" . IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" .
IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" . IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .
ENUM uses the same 'u' flag as the URI Resolution Application. This Both the ENUM [18] and URI Resolution [4] Applications use the 'u'
flag states that the Rule is terminal and that the output is a URL flag. This flag states that the Rule is terminal and that the output
which contains the information needed to contact that telephone is a URI which contains the information needed to contact that
service. ENUM also uses the same format for its Service Parameters. telephone service. ENUM also uses the same format for its Service
These state that the available protocols used to access that Parameters. These state that the available protocols used to access
telephone's service are either the Session Initiation Protocol or that telephone's service are either the Session Initiation Protocol
SMTP mail. or SMTP mail.
7. Advice for DNS Administrators 7. Advice for DNS Administrators
Beware of regular expressions. Not only are they difficult to get Beware of regular expressions. Not only are they difficult to get
correct on their own, but there is the previously mentioned correct on their own, but there is the previously mentioned
interaction with DNS. Any backslashes in a regexp must be entered interaction with DNS. Any backslashes in a regexp must be entered
twice in a zone file in order to appear once in a query response. twice in a zone file in order to appear once in a query response.
More seriously, the need for double backslashes has probably not been More seriously, the need for double backslashes has probably not been
tested by all implementors of DNS servers. tested by all implementors of DNS servers.
In order to mitigate zone file problems, administrators should In order to mitigate zone file problems, administrators should
encourage those writing rewrite rules to utilize the 'default encourage those writing rewrite rules to utilize the 'default
delimiter' feature of the regular expression. In the DDDS delimiter' feature of the regular expression. In the DDDS
specification the regular expression starts with the character that specification the regular expression starts with the character that
is to be the delimiter. Hence if the first character of the regular is to be the delimiter. Hence if the first character of the regular
expression is an exclamation mark ('!') for example then the regular expression is an exclamation mark ('!') for example then the regular
expression can usually be written without any backslashes. expression can usually be written with fewer backslashes.
8. Notes 8. Notes
A client MUST process multiple NAPTR records in the order A client MUST process multiple NAPTR records in the order
specified by the "order" field, it MUST NOT simply use the first specified by the "order" field, it MUST NOT simply use the first
record that provides a known Service Parameter combination. record that provides a known Service Parameter combination.
When multiple RRs have the same "order" and all other criteria When multiple RRs have the same "order" and all other criteria
being equal, the client should use the value of the preference being equal, the client should use the value of the preference
field to select the next NAPTR to consider. However, because it field to select the next NAPTR to consider. However, because it
skipping to change at page 18, line 9 skipping to change at page 18, line 9
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] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf- One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-
urn-ddds-toc-00.txt (work in progress), October 2001. urn-ddds-toc-02.txt (work in progress), February 2002.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work
in progress), May 2000. in progress), February 2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-
database-07.txt (work in progress), May 2000. database-07.txt (work in progress), February 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The URI Resolution Application", RFC YYYY, draft-ietf- Four: The URI Resolution Application", RFC YYYY, draft-ietf-
urn-uri-res-ddds-05.txt (work in progress), October 2000. urn-uri-res-ddds-06.txt (work in progress), February 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf- Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-
urn-net-procedures-09.txt (work in progress), October 2001. urn-net-procedures-10.txt (work in progress), February 2002.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [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.
[7] 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.
[8] 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.
skipping to change at page 19, line 16 skipping to change at page 19, line 16
[15] 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.
[16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource [16] 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.
[17] 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.
[18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
Author's Address Author's Address
Michael Mealling Michael Mealling
VeriSign VeriSign
505 Huntmar Park Drive 21345 Ridgetop Circle
Herndon, VA 22070 Sterling, VA 20166
US US
Phone: +1 770 921-2251 EMail: michael@neonym.net
EMail: michael@research.netsol.com URI: http://www.verisignlabs.com
URI: http://www.verisign.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 23 change blocks. 
46 lines changed or deleted 59 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/