draft-ietf-urn-dns-ddds-database-02.txt   draft-ietf-urn-dns-ddds-database-03.txt 
Network Working Group M. Mealling Network Working Group M. Mealling
Internet-Draft Network Solutions, Inc. Internet-Draft Verisign
Expires: May 2, 2001 November 1, 2000 Expires: August 1, 2000 February 2000
A DDDS Database Using The Domain Name System A DDDS Database Using The Domain Name System
draft-ietf-urn-dns-ddds-database-02 draft-ietf-urn-dns-ddds-database-03
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-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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 To view the entire list of Internet-Draft Shadow Directories, see
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 May 2, 2001. This Internet-Draft will expire on August 1, 2000.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). 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
skipping to change at page 5, line 41 skipping to change at page 5, line 41
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 DNS zone but they apply to more than
one Appliation. There are three ways to avoid collisions: one Appliation. There are three ways to avoid collisions:
* create a new DNS zone in the zone which the administrator has * create a new DNS zone in the zone which the administrator has
authority that contains only NAPTR records that are authority that contains only NAPTR records that are
appropriate for the application. E.g., all URI Resolution appropriate for the application. E.g., all URI Resolution
records are put into urires.foo.com and all ENUM records are records are put into urires.example.com and all ENUM records
put into enum.foo.com. In the case where this is not possible are put into enum.example.com. In the case where this is not
due to lack of control over the upstream delegation the second possible due to lack of control over the upstream delegation
method is used. the second 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 regular expression match to that scheme. An ENUM specific the 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. This way a given Appliation Unique String can only String. This way a given Appliation Unique String can only
skipping to change at page 11, line 18 skipping to change at page 11, line 18
The NAPTR record was originally specified for use with the a Uniform The NAPTR record was originally specified for use with the a 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.foo.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 between the first and second colon. For this URN that characters between the first and second colon. For this URN that
would be 'cid'. The Application also specifies that, in order to would be 'cid'. The Application also specifies that, in order to
build a Database-valid Key, the string 'urn.arpa' should be appended build a Database-valid Key, the string 'urn.arpa' should be appended
to the result of the First Well Known Rule. The result is to the 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-name 'cid.urn.arpa'. The result is a single record: domain-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 "foo.com". Since the flags field is expression returns the string "example.com". Since the flags field
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
more NAPTR records where the new domain is 'foo.com'. for 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 be an intolerable burden. Wildcards are not appropriate here could be an intolerable burden. Wildcards are not appropriate here
since they only return results when there is no exactly matching since they only return results when there is no exactly matching
names already in the system. names already in the system.
The record returned from the query on "foo.com" might look like: The record returned from the query on "example.com" might look like:
foo.com. example.com.
;; order pref flags service regexp replacement ;; order pref flags service regexp replacement
IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.foo.com. IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.foo.com. IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.foo.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-name for which an A record should be queried. Once the client domain-name for which an A record should be queried. Once the client
has done that, it has the following information: the host, its IP has 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.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
entire Key is inverted and then "e164.arpa" is appended to the end. entire Key is inverted and then "e164.arpa" is appended to the end.
The above telephone number would then read The above telephone number would then read
"2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to
retrieve Rewrite Rules as NAPTR records. retrieve Rewrite Rules as NAPTR records.
For this example telephone number we might get back the following For this example telephone number we might get back the following
NAPTR records: NAPTR records:
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
IN NAPTR 100 10 "u" "sip+N2R" "!^.*$!sip:information@tele2.se!" . IN NAPTR 100 10 "u" "sip+N2R" "!^.*$!sip:information@foo.se!" .
IN NAPTR 102 10 "u" "smtp+N2R" "!^.*$!mailto:information@tele2.se!" . IN NAPTR 102 10 "u" "smtp+N2R" "!^.*$!mailto:information@foo.se!" .
ENUM uses the same 'u' flag as the URI Resolution Application. This ENUM uses the same 'u' flag as the URI Resolution Application. This
flag states that the Rule is terminal and that the output is a URL flag states that the Rule is terminal and that the output is a URL
which contains the information needed to contact that telephone which contains the information needed to contact that telephone
service. ENUM also uses the same format for its Service Parameters. service. ENUM also uses the same format for its Service Parameters.
These state that the available protocols used to access that These state that the available protocols used to access that
telephone's service are either the Session Initiation Protocol or telephone's service are either the Session Initiation Protocol or
SMTP mail. SMTP mail.
7. Advice for DNS Administrators 7. Advice for DNS Administrators
skipping to change at page 17, line 15 skipping to change at page 17, line 15
10. Security Considerations 10. Security Considerations
The NAPTR record, like any other DNS record, can be signed and The NAPTR record, like any other DNS record, can be signed and
validated according to the procedures specified in DNSSEC. validated according to the procedures specified in DNSSEC.
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. to something like PERL since arbitrary code can be included and
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.V., "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.V., "Domain names - concepts and facilities",
skipping to change at page 19, line 8 skipping to change at page 19, line 8
[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] "Appendix A.2 of "The Unicode Standard, Version 2.0"", ISBN [15] "Appendix A.2 of "The Unicode Standard, Version 2.0"", ISBN
0-201-48345-9, January 1996. 0-201-48345-9, January 1996.
Author's Address Author's Address
Michael Mealling Michael Mealling
Network Solutions, Inc. Verisign
505 Huntmar Park Drive 505 Huntmar Park Drive
Herndon, VA 22070 Herndon, VA 22070
US US
Phone: +1 770 935 5492 Phone: +1 770 921-2251
EMail: michaelm@netsol.com EMail: michaelm@netsol.com
URI: http://www.netsol.com URI: http://www.verisign.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). 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 implmentation 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
 End of changes. 15 change blocks. 
27 lines changed or deleted 25 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/