draft-ietf-urn-dns-ddds-database-04.txt   draft-ietf-urn-dns-ddds-database-05.txt 
Network Working Group M. Mealling Network Working Group M. Mealling
Internet-Draft Verisign Internet-Draft Verisign
Expires: August 31, 2001 March 2, 2001 Expires: November 23, 2001 May 25, 2001
A DDDS Database Using The Domain Name System A DDDS Database Using The Domain Name System
draft-ietf-urn-dns-ddds-database-04 draft-ietf-urn-dns-ddds-database-05
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 other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
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."
To view the entire list of Internet-Draft Shadow Directories, see 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. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 31, 2001. This Internet-Draft will expire on November 23, 2001.
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 Since this document officially obsoletes RFC 2915, it is the official
official specification for the NAPTR DNS Resource Record. specification for the NAPTR DNS Resource Record.
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 Master File Format . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Master File Format . . . . . . . . . . . . . . . . . . . . . . 9
5. Application Specifications . . . . . . . . . . . . . . . . . . 10 5. Application Specifications . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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 NAPTR DNS Resource Record was originally produced by the URN
Working Group as a way to encode rule-sets in DNS so that the 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 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 they could be changed and re-delegated over time. The result was a
Resource Record that included a regular expression that would be Resource Record that included a regular expression that would be used
used by a client program to rewrite a string into a domain name. by a client program to rewrite a string into a domain name. Regular
Regular expressions were chosen for their compactness to expressions were chosen for their compactness to expressivity ratio
expressivity ratio allowing for a great deal of information to be allowing for a great deal of information to be encoded in a rather
encoded in a rather small DNS packet. 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 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 ZZZZ [11] and RFC XXXX [12], obsoletes RFC 2168 [14], RFC 2915 [13]
updates RFC 2276[10]. 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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
All other terminology, especially capitalized terms, is taken from All other terminology, especially capitalized terms, is taken from
[11]. [11].
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]. [3] and [2].
skipping to change at page 5, line 28 skipping to change at page 5, line 28
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.
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:
In order to request a set of rules for a given Key, the client In order to request a set of rules for a given Key, the client
issues a request, following standard DNS rules, for NAPTR issues a request, following standard DNS rules, for NAPTR Resource
Resource Records for the given domain-name. Records for the given domain-name.
Lookup Response: Lookup Response:
The response to a request for a given Key (domain-name) will be a The response to a request for a given Key (domain-name) will be a
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 Application 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 DNS zone but they apply to more than records appear in the same domain but they apply to more than one
one Appliation. There are three ways to avoid collisions: Appliation. There are three ways to avoid collisions:
* create a new DNS zone in the zone which the administrator has * create a new zone within the domain in common that contains
authority that contains only NAPTR records that are only NAPTR records that are appropriate for the application.
appropriate for the application. E.g., all URI Resolution E.g., all URI Resolution records would exist under
records are put into urires.example.com and all ENUM records urires.example.com and all ENUM records would be under
are put into enum.example.com. In the case where this is not enum.example.com. In the case where this is not possible due
possible due to lack of control over the upstream delegation to lack of control over the upstream delegation the second
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 able to use the scheme name on the left hand side to anchor the
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 ENUM to be at the beginning of every Application Unique String.
String. This way a given Appliation Unique String can only This way a given Appliation Unique String can only match one or
match one or the other record, not both. 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
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[1]. RFC1035 [2].
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.
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 terminology, this field is equivalent to the Priority value in the
the DDDS Algorithm. It is a 16-bit unsigned integer that DDDS Algorithm. It is a 16-bit unsigned integer that specifies
specifies the order in which NAPTR records with equal Order the order in which NAPTR records with equal Order values SHOULD be
values SHOULD be processed, low numbers being processed before processed, low numbers being processed before high numbers. This
high numbers. This is similar to the preference field in an MX is similar to the preference field in an MX record, and is used so
record, and is used so domain administrators can direct clients domain administrators can direct clients towards more capable
towards more capable hosts or lighter weight protocols. A client hosts or lighter weight protocols. A client MAY look at records
MAY look at records with higher preference values if it has a with higher preference values if it has a good reason to do so
good reason to do so such as not understanding some protocol or such as not understanding some protocol or service.
service.
The important difference between Order and Preference is that The important difference between Order and Preference is that once
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 weight but different Preferences. I.e. Preference is used to give
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-Z0-9]. The case of the
alphabetic characters is not significant. alphabetic characters is not significant.
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
skipping to change at page 8, line 40 skipping to change at page 8, line 40
REGEXP REGEXP
A <character-string> containing a substitution expression that is A <character-string> containing a substitution expression that is
applied to the original string held by the client in order to applied to the original string held by the client in order to
construct the next domain name to lookup. See the DDDS Algorithm construct the next domain name to lookup. See the DDDS Algorithm
specification for the syntax of this field. specification for the syntax of this field.
As stated in the DDDS algorithm, The regular expressions MUST NOT As stated in the DDDS algorithm, The regular expressions MUST NOT
be used in a cumulative fashion, that is, they should only be be used in a cumulative fashion, that is, they should only be
applied to the original string held by the client, never to the applied to the original string held by the client, never to the
domain name produced by a previous NAPTR rewrite. The latter is domain name produced by a previous NAPTR rewrite. The latter is
tempting in some applications but experience has shown such use tempting in some applications but experience has shown such use to
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 specifies the The next domain-name to query A <domain-name> which is the next domain-name to query for
for depending on the potential values found in the flags field. depending on the potential values found in the flags field. This
This field is used when the regular expression is a simple field is used when the regular expression is a simple replacement
replacement operation. Any value in this field MUST be a fully operation. Any value in this field MUST be a fully qualified
qualified domain-name. Unless and until permitted by future domain-name. Name compression is not to be used for this field.
standards action, name compression is not to be used for this This field and the REGEXP field together make up the Substitution
field. This field and the REGEXP field together make up the Expression in the DDDS Algorithm. They are also mutually
Substitution Expression in the DDDS Algorithm. They are also exclusive. If a record is returned that has values for both
mutually exclusive. If a record is returned that has values for fields then it is considered to be in error and should be ignored.
both fields then it is considered to be in error and should be
ignored.
4.2 Master File Format 4.2 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[1].
Order and preference, being 16-bit unsigned integers, shall be an Order and preference, being 16-bit unsigned integers, shall be an
integer between 0 and 65535. The Flags and Services and Regexp integer between 0 and 65535. The Flags and Services and Regexp
fields are all quoted <character-string>s. Since the Regexp field fields are all quoted <character-string>s. Since the Regexp field
can contain numerous backslashes and thus should be treated with can contain numerous backslashes and thus should be treated with
care. See Section 10 for how to correctly enter and escape the care. See Section 10 for how to correctly enter and escape the
regular expression. regular expression.
5. Application Specifications 5. Application Specifications
This DDDS Database is usable by any application that makes use of This DDDS Database is usable by any application that makes use of the
the DDDS algorithm. In addition to the items required to specify a DDDS algorithm. In addition to the items required to specify a DDDS
DDDS Application, an application wishing to use this Database must Application, an application wishing to use this Database must also
also define the following values: define the following values:
o What DNS zone the Key that is produced by the First Well Known o What domain the Key that is produced by the First Well Known Rule
Rule belongs to. Any application must ensure that its rules do belongs to. Any application must ensure that its rules do not
not collide with rules used by another application making use of collide with rules used by another application making use of this
this Database. For example, the 'foo' application might have all Database. For example, the 'foo' application might have all of
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
6. Examples 6. Examples
6.1 URN Example 6.1 URN Example
The NAPTR record was originally specified for use with the a 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 [12] 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 This Application's First Well Known Rule is to extract the characters
characters between the first and second colon. For this URN that between the first and second colon. For this URN that would be
would be 'cid'. The Application also specifies that, in order to 'cid'. The Application also specifies that, in order to build a
build a Database-valid Key, the string 'urn.arpa' should be appended Database-valid Key, the string 'urn.arpa' should be appended to the
to the result of the First Well Known Rule. The result is result of the First Well Known Rule. The result is 'cid.urn.arpa'.
'cid.urn.arpa'.
Next, the client queries the DNS for NAPTR records for the Next, the client queries the DNS for NAPTR records for the domain-
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 is empty, the lookup is not terminal and our next probe to DNS is for
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 NAPTR, maintaining those records for all the machines at a site could
could be an intolerable burden. Wildcards are not appropriate here be an intolerable burden. Wildcards are not appropriate here since
since they only return results when there is no exactly matching they only return results when there is no exactly matching names
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 terminal lookup and that the output of the rewrite will be a domain-
domain-name for which an A record should be queried. Once the client name for which an A record should be queried. Once the client has
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 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 "!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually
actually receives the record, the pattern will have been converted receives the record, the pattern will have been converted to
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. The Application
Unique String for the ENUM Application is the E.164 telephone number Unique String for the ENUM Application is the E.164 telephone number
with the dashes removed. The First Well Known Rule is to remove all with the dashes removed. The First Well Known Rule is to remove all
characters from the the telephone number and then use the entire characters from the the telephone number and then use the entire
number as the first Key. For example, the phone number number as the first Key. For example, the phone number "770-555-
"770-555-1212" represented as an E.164 number would be 1212" represented as an E.164 number would be "+1-770-555-1212".
"+1-770-555-1212". Converted to the Key it would be "17705551212". 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
skipping to change at page 14, line 11 skipping to change at page 14, line 11
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
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 More seriously, the need for double backslashes has probably not been
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 without any backslashes.
8. Notes 8. Notes
skipping to change at page 18, line 10 skipping to change at page 18, line 10
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] 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.V., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, STD 13, Nov 1987. specification", RFC 1035, STD 13, Nov 1987.
[3] Mockapetris, P.V., "Domain names - concepts and facilities", [3] Mockapetris, P., "Domain names - concepts and facilities", RFC
RFC 1034, STD 13, Nov 1987. 1034, STD 13, Nov 1987.
[4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [4] 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", [5] 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 [6] 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 [7] 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.T. and L. Masinter, "Uniform [8] 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. [9] Moats, R., "URN Syntax", RFC 2141, May 1997.
[10] Sollins, K., "Architectural Principles of Uniform Resource [10] Sollins, K., "Architectural Principles of Uniform Resource Name
Name Resolution", RFC 2276, January 1998. Resolution", RFC 2276, January 1998.
[11] Mealling, M., "Dynamic Delegation Discovery System (DDDS)", [11] Mealling, M., "Dynamic Delegation Discovery System (DDDS)", RFC
RFC ZZZZ, Internet-Draft draft-ietf-urn-ddds-00.txt, May 2000. ZZZZ, draft-ietf-urn-ddds-00.txt (work in progress), May 2000.
[12] Mealling, M., "URI Resolution using the Dynamic Delegation [12] Mealling, M., "URI Resolution using the Dynamic Delegation
Discovery System", RFC XXXX, Internet-Draft Discovery System", RFC XXXX, draft-ietf-urn-uri-res-ddds-00.txt
draft-ietf-urn-uri-res-ddds-00.txt, July 2000. (work in progress), July 2000.
[13] Mealling, M. and R. Daniel, "The Naming Authority Pointer [13] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, August 2000. (NAPTR) DNS Resource Record", RFC 2915, August 2000.
[14] Daniel, R. and M. Mealling, "Resolution of Uniform Resource [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", [15] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
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
Phone: +1 770 921-2251 Phone: +1 770 921-2251
EMail: michaelm@netsol.com EMail: michaelm@netsol.com
URI: http://www.verisign.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 (2001). 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 implmentation 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 kind, provided that the above copyright notice and this paragraph are
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
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 42 change blocks. 
115 lines changed or deleted 114 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/