draft-ietf-urn-dns-ddds-database-09.txt   rfc3403.txt 
Network Working Group M. Mealling Network Working Group M. Mealling
Internet-Draft VeriSign Request for Comments: 3403 VeriSign
Expires: November 5, 2002 May 7, 2002 Obsoletes: 2915, 2168 October 2002
Category: Standards Track
Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Dynamic Delegation Discovery System (DDDS)
Database Part Three: The Domain Name System (DNS) Database
draft-ietf-urn-dns-ddds-database-09.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 5, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). 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 (DDDS)
Database using the Domain Name System as a distributed database of Database using the Domain Name System (DNS) as a distributed database
Rules. The Keys are domain-names and the Rules are encoded using the of Rules. The Keys are domain-names and the Rules are encoded using
NAPTR Resource Record. the Naming Authority Pointer (NAPTR) Resource Record (RR).
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
a series that is completely specified in "Dynamic Delegation a series that is completely specified in "Dynamic Delegation
Discovery System (DDDS) Part One: The Comprehensive DDDS Standard" Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401).
(RFC WWWW). It is very important to note that it is impossible to It is very important to note that it is impossible to read and
read and understand any document in this series without reading the understand any document in this series without reading the others.
others.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DDDS Database Specification . . . . . . . . . . . . . . . . 5 3. DDDS Database Specification . . . . . . . . . . . . . . . . 3
4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 7 4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Additional Information Processing . . . . . . . . . . . . . 9 4.2 Additional Information Processing . . . . . . . . . . . . . 7
4.2.1 Additional Section processing by DNS servers . . . . . . . . 9 4.2.1 Additional Section processing by DNS servers . . . . . . . . 7
4.2.2 Additional Section processing by resolver/applications . . . 9 4.2.2 Additional Section processing by resolver/applications . . . 7
4.3 Master File Format . . . . . . . . . . . . . . . . . . . . . 9 4.3 Master File Format . . . . . . . . . . . . . . . . . . . . . 7
5. Application Specifications . . . . . . . . . . . . . . . . . 10 5. Application Specifications . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Advice for DNS Administrators . . . . . . . . . . . . . . . 14 7. Advice for DNS Administrators . . . . . . . . . . . . . . . 10
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Dynamic Delegation Discovery System is used to implement lazy The Dynamic Delegation Discovery System (DDDS) is used to implement
binding of strings to data, in order to support dynamically lazy binding of strings to data, in order to support dynamically
configured delegation systems. The DDDS functions by mapping some configured delegation systems. The DDDS functions by mapping some
unique string to data stored within a DDDS Database by iteratively unique string to data stored within a DDDS Database by iteratively
applying string transformation rules until a terminal condition is applying string transformation rules until a terminal condition is
reached. reached.
This document describes the way in which the Domain Name System is This document describes the way in which the Domain Name System (DNS)
used as a data store for the Rules that allow a DDDS Application to is used as a data store for the Rules that allow a DDDS Application
function. It does not specify any particular application or usage to function. It does not specify any particular application or usage
scenario. The entire series of documents is specified in "Dynamic scenario. The entire series of documents is specified in "Dynamic
Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS"
Standard" (RFC WWWW) [1]. It is very important to note that it is (RFC 3401) [1]. It is very important to note that it is impossible
impossible to read and understand any document in that series without to read and understand any document in that series without reading
reading the related documents. the related documents.
The NAPTR DNS Resource Record specified here was originally produced The Naming Authority Pointer (NAPTR) DNS Resource Record (RR)
by the URN Working Group as a way to encode rule-sets in DNS so that specified here was originally produced by the URN Working Group as a
the delegated sections of a URI could be decomposed in such a way way to encode rule-sets in DNS so that the delegated sections of a
Uniform Resource Identifiers (URI) could be decomposed in such a way
that they could be changed and re-delegated over time. The result that they could be changed and re-delegated over time. The result
was a Resource Record that included a regular expression that would 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. be used by a client program to rewrite a string into a domain name.
Regular expressions were chosen for their compactness to expressivity Regular expressions were chosen for their compactness to expressivity
ratio allowing for a great deal of information to be encoded in a ratio allowing for a great deal of information to be encoded in a
rather small DNS packet. 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.
2. Terminology 2. Terminology
skipping to change at page 4, line 8 skipping to change at page 3, line 17
rather small DNS packet. 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.
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 [6]. 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
[3]. [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
[8] and [7]. [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 [17]. 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 substitution
expressions to loose their ability to be universally applicable. expressions to loose their ability to be universally applicable.
All DNS resource records have a Time To Live (TTL) associated with All DNS resource records have a Time To Live (TTL) associated with
them. When the number of seconds has passed since the record was them. When the number of seconds has passed since the record was
retrieved the record is no longer valid and a new query must be retrieved the record is no longer valid and a new query must be
used to retrieve the new records. Thus, as mentioned in the DDDS used to retrieve the new records. Thus, as mentioned in the DDDS
Algorithm, there can be the case where a given Rule expires. In Algorithm, there can be the case where a given Rule expires. In
the case where an application attemps to fall back to previously the case where an application attempts to fall back to previously
retrieved sets of Rules (either in the case of a bad delegation retrieved sets of Rules (either in the case of a bad delegation
path or some network or server failure) the application MUST path or some network or server failure) the application MUST
ensure that none of the records it is relying on have expired. In ensure that none of the records it is relying on have expired. In
the case where even a single record has expired, the application the case where even a single record has expired, the application
is required to start over at the beginning of the algorithm. is required to start over at the beginning of the algorithm.
Key Format: Key Format:
A Key is a validly constructed DNS domain-name. A Key is a validly constructed DNS domain-name.
Lookup Request: Lookup Request:
skipping to change at page 6, line 10 skipping to change at page 4, line 29
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,
Section 6.2), there is a chance of collision between rules where Section 6.2), there is a chance of collision between rules where
two NAPTR records appear in the same domain but they apply to more two NAPTR records appear in the same domain but they apply to more
than one Appliation. There are three ways to avoid collisions: than one Application. 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
the Application Unique string to disambiguate it from any the Application Unique string to disambiguate it from any
other. For example, the URI Resolution Application would be other. For example, the URI Resolution Application would be
able to use the scheme name on the left hand side to anchor the able to use the scheme name on the left hand side to anchor the
regular expression match to that scheme. An ENUM specific regular expression match to that scheme. An ENUM specific
record in that same zone would be able to anchor the left hand record in that same zone would be able to anchor the left hand
side of the match with the "+" character which is defined by side of the match with the "+" character which is defined by
ENUM to be at the beginning of every Application Unique String. ENUM to be at the beginning of every Application Unique String.
This way a given Appliation Unique String can only match one or This way a given Application Unique String can only match one
the other record, not both. or the other record, not both.
* if two Application use different Flags or Services values then * if two Application use different Flags or Services values then
a record from another Application will be ignored since it a record from another Application will be ignored since it
doesn't apply to the Services/Flags in question. doesn't apply to the Services/Flags in question.
4. NAPTR RR Format 4. NAPTR RR Format
4.1 Packet Format 4.1 Packet Format
The packet format of the NAPTR RR is given below. The DNS type code The packet format of the NAPTR RR is given below. The DNS type code
for NAPTR is 35. for NAPTR is 35.
The packet format for the NAPTR record is as follows The packet format for the NAPTR record is as follows
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ORDER | | ORDER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE | | PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ FLAGS / / FLAGS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ 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 RFC
RFC1035 [7]. 1035 [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 based on the to be the same rule and should be selected based on the
combination of the Preference values and Services offered. combination of the Preference values and Services offered.
PREFERENCE PREFERENCE
skipping to change at page 9, line 25 skipping to change at page 7, line 25
exists. The fields are also mutually exclusive. If a record is exists. The fields are also mutually exclusive. If a record is
returned that has values for both fields then it is considered to returned that has values for both fields then it is considered to
be in error and SHOULD be either ignored or an error returned. 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
are relevant to the answer and have the same authenticity as the data are relevant to the answer and have the same authenticity as the data
in the answer section. Generally this will be made up of A and SRV in the answer section. Generally this will be made up of A and SRV
records but the exact records depends on the application. records but the exact records depends on the application.
4.2.2 Additional Section processing by resolver/applications 4.2.2 Additional Section Processing by Resolver/Applications
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
skipping to change at page 11, line 10 skipping to change at page 8, line 28
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 in o What the expected output is of the terminal rewrite rule in
addition to how the Flags are actually encoded and utilized. 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 (URN) Resolver Discovery Service (RDS) [15]. This
particular URN would use the NAPTR record to find a resolver service example details how a particular URN would use the NAPTR record to
that can answer questions about the URN. See [2] for the definitive find a resolver service that can answer questions about the URN. See
specification for this Application. [2] for the definitive 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
Database-valid Key, the string 'urn.arpa' should be appended to the Database-valid Key, the string 'urn.arpa' should be appended to the
skipping to change at page 11, line 25 skipping to change at page 8, line 43
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
Database-valid Key, the string 'urn.arpa' should be appended to the Database-valid Key, the string 'urn.arpa' should be appended to the
result of the First Well Known Rule. The result is 'cid.urn.arpa'. result of the First Well Known Rule. The result is 'cid.urn.arpa'.
Next, the client queries the DNS for NAPTR records for the domain- Next, the client queries the DNS for NAPTR records for the domain-
name 'cid.urn.arpa'. The result is a single record: name 'cid.urn.arpa'. The result is a single record:
cid.urn.arpa. cid.urn.arpa.
;; order pref flags service regexp replacement ;; order pref flags service regexp replacement
IN NAPTR 100 10 "" "" "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i" . IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .
Since there is only one record, ordering the responses is not a Since there is only one record, ordering the responses is not a
problem. The replacement field is empty, so the pattern provided in 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 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 see if it matches, which it does. The \2 part of the substitution
expression returns the string "example.com". Since the flags field expression returns the string "example.com". Since the flags field
is empty, the lookup is not terminal and our next probe to DNS is for is empty, the lookup is not terminal and our next probe to DNS is for
more NAPTR records where the new domain is 'example.com'. more NAPTR records where the new domain is 'example.com'.
Note that the rule does not extract the full domain name from the 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 CID, instead it assumes the CID comes from a host and extracts its
domain. While all hosts, such as 'bar', could have their very own domain. While all hosts, such as 'bar', could have their very own
NAPTR, maintaining those records for all the machines at a site could NAPTR, maintaining those records for all the machines at a site could
be an intolerable burden. Wildcards are not appropriate here since be an intolerable burden. Wildcards are not appropriate here since
they only return results when there is no exactly matching names they only return results when there is no exactly matching names
already in the system. already in the system.
The record returned from the query on "example.com" might look like: The record returned from the query on "example.com" might look like:
example.com. example.com.
;; order pref flags service regexp replacement ;; order pref flags service regexp replacement
IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com.
Continuing with the example, note that the values of the order and 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 preference fields are equal in all records, so the client is free to
pick any record. The Application defines the flag 'a' to mean a pick any record. The Application defines the flag 'a' to mean a
terminal lookup and that the output of the rewrite will be a domain- terminal lookup and that the output of the rewrite will be a domain-
name for which an A record should be queried. Once the client has name for which an A record should be queried. Once the client has
done that, it has the following information: the host, its IP done that, it has the following information: the host, its IP
address, the protocol, and the services available via that protocol. address, the protocol, and the services available via that protocol.
Given these bits of information the client has enough to be able to Given these bits of information the client has enough to be able to
contact that server and ask it questions about the URN. contact that server and ask it questions about the URN.
Recall that the regular expression used \2 to extract a domain name Recall that the regular expression used \2 to extract a domain name
from the CID, and \. for matching the literal '.' characters from the CID, and \. for matching the literal '.' characters
separating the domain name components. Since '\' is the escape separating the domain name components. Since '\' is the escape
character, literal occurances of a backslash must be escaped by character, literal occurrences 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
receives the record, the pattern will have been converted to actually 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 [18]. The allows a telephone number to be mapped to a URI [18]. The
Application Unique String for the ENUM Application is the E.164 Application Unique String for the ENUM Application is the E.164
telephone number with the dashes removed. The First Well Known Rule telephone number with the dashes removed. The First Well Known Rule
is to remove all characters from the the telephone number and then is to remove all characters from the the telephone number and then
use the entire number as the first Key. For example, the phone use the entire number as the first Key. For example, the phone
number "770-555-1212" represented as an E.164 number would be "+1- number "770-555-1212" represented as an E.164 number would be "+1-
skipping to change at page 13, line 5 skipping to change at page 10, line 27
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" .
Both the ENUM [18] and URI Resolution [4] Applications use the 'u' Both the ENUM [18] and URI Resolution [4] Applications use the 'u'
flag. This flag states that the Rule is terminal and that the output flag. This flag states that the Rule is terminal and that the output
is a URI which contains the information needed to contact that is a URI which contains the information needed to contact that
telephone service. ENUM also uses the same format for its Service telephone service. ENUM also uses the same format for its Service
Parameters. These state that the available protocols used to access Parameters. These state that the available protocols used to access
that telephone's service are either the Session Initiation Protocol that telephone's service are either the Session Initiation Protocol
or SMTP mail. or SMTP mail.
7. Advice for DNS Administrators 7. Advice for DNS Administrators
skipping to change at page 15, line 7 skipping to change at page 11, line 15
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 with fewer 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
specified by the "order" field, it MUST NOT simply use the first by the "order" field, it MUST NOT simply use the first record that
record that provides a known Service Parameter combination. 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
being equal, the client should use the value of the preference equal, the client should use the value of the preference field to
field to select the next NAPTR to consider. However, because it select the next NAPTR to consider. However, because it will often be
will often be the case where preferred protocols or services the case where preferred protocols or services exist, clients may use
exist, clients may use this additional criteria to sort the this additional criteria to sort the records.
records.
If the lookup after a rewrite fails, clients are strongly If the lookup after a rewrite fails, clients are strongly encouraged
encouraged to report a failure, rather than backing up to pursue to report a failure, rather than backing up to pursue other rewrite
other rewrite paths. paths.
9. IANA Considerations 9. IANA Considerations
The values for the Services and Flags fields will be determined by The values for the Services and Flags fields will be determined by
the Application that makes use of this DDDS Database. Those values the Application that makes use of this DDDS Database. Those values
may require a registration mechanism and thus may need some IANA may require a registration mechanism and thus may need some IANA
resources. This specification by itself does not. resources. This specification by itself does not.
10. Security Considerations 10. Security Considerations
skipping to change at page 18, line 7 skipping to change at page 12, 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] 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", RFC 3401, October 2002.
urn-ddds-toc-03.txt (work in progress), May 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-07.txt (work Two: The Algorithm", RFC 3402, October 2002.
in progress), May 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 Domain Name System (DNS) Database", RFC 3403, October
database-09.txt (work in progress), May 2002. 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 Uniform Resource Identifiers (URI) Resolution
urn-uri-res-ddds-07.txt (work in progress), May 2002. Application", RFC 3404, October 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 3405, October 2002.
urn-net-procedures-11.txt (work in progress), May 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", BCP 14, RFC 2119, March 1997.
[7] Mockapetris, P., "Domain names - implementation and [7] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, STD 13, Nov 1987. specification", STD 13, RFC 1035, November 1987.
[8] Mockapetris, P., "Domain names - concepts and facilities", RFC [8] Mockapetris, P., "Domain names - concepts and facilities", STD
1034, STD 13, Nov 1987. 13, RFC 1034, November 1987.
[9] 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.
[10] 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.
[11] 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.
[12] 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
Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993. (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
[13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
1998.
[14] Moats, R., "URN Syntax", RFC 2141, May 1997. [14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[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 [18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
2000.
Author's Address Author's Address
Michael Mealling Michael Mealling
VeriSign VeriSign
21345 Ridgetop Circle 21345 Ridgetop Circle
Sterling, VA 20166 Sterling, VA 20166
US US
EMail: michael@neonym.net EMail: michael@neonym.net
 End of changes. 49 change blocks. 
168 lines changed or deleted 147 lines changed or added

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