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