draft-ietf-urn-dns-ddds-database-07.txt		draft-ietf-urn-dns-ddds-database-08.txt
	Network Working Group M. Mealling		Network Working Group M. Mealling
	Internet-Draft VeriSign		Internet-Draft VeriSign
	Expires: April 28, 2002 October 28, 2001		Expires: August 20, 2002 February 19, 2002
	Dynamic Delegation Discovery System (DDDS) Part Three: The DNS		Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
	Database		Database
	draft-ietf-urn-dns-ddds-database-07.txt		draft-ietf-urn-dns-ddds-database-08.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32		skipping to change at page 1, line 32
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 28, 2002.		This Internet-Draft will expire on August 20, 2002.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract		Abstract
	This document describes a Dynamic Delegation Discovery System		This document describes a Dynamic Delegation Discovery System
	Database using the Domain Name System as a distributed database of		Database using the Domain Name System as a distributed database of
	Rules. The Keys are domain-names and the Rules are encoded using the		Rules. The Keys are domain-names and the Rules are encoded using the
	NAPTR Resource Record.		NAPTR Resource Record.
	Since this document obsoletes RFC 2915, it is the official		Since this document obsoletes RFC 2915, it is the official
	specification for the NAPTR DNS Resource Record. It is also part of		specification for the NAPTR DNS Resource Record. It is also part of
	skipping to change at page 5, line 44		skipping to change at page 5, line 44
	can be found in Section 4.		can be found in Section 4.
	Rule Insertion Procedure:		Rule Insertion Procedure:
	Rules are inserted by adding new records to the appropriate DNS		Rules are inserted by adding new records to the appropriate DNS
	zone. If a Rule produces a Key that exists in a particular zone		zone. If a Rule produces a Key that exists in a particular zone
	then only the entity that has administrative control of that zone		then only the entity that has administrative control of that zone
	can specify the Rule associated with that Key.		can specify the Rule associated with that Key.
	Collision Avoidance:		Collision Avoidance:
	In the case where two Applications may use this Database (which is		In the case where two Applications may use this Database (which is
	actually the case with the ENUM and URI Resolution Applications),		actually the case with the ENUM and URI Resolution Applications,
	there is a chance of collision between rules where two NAPTR		Section 6.2), there is a chance of collision between rules where
	records appear in the same domain but they apply to more than one		two NAPTR records appear in the same domain but they apply to more
	Appliation. There are three ways to avoid collisions:		than one Appliation. There are three ways to avoid collisions:
	* create a new zone within the domain in common that contains		* create a new zone within the domain in common that contains
	only NAPTR records that are appropriate for the application.		only NAPTR records that are appropriate for the application.
	E.g., all URI Resolution records would exist under		E.g., all URI Resolution records would exist under
	urires.example.com and all ENUM records would be under		urires.example.com and all ENUM records would be under
	enum.example.com. In the case where this is not possible due		enum.example.com. In the case where this is not possible due
	to lack of control over the upstream delegation the second		to lack of control over the upstream delegation the second
	method is used.		method is used.
	* write the regular expression such that it contains enough of		* write the regular expression such that it contains enough of
	skipping to change at page 7, line 38		skipping to change at page 7, line 38
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	<character-string> and <domain-name> as used here are defined in		<character-string> and <domain-name> as used here are defined in
	RFC1035 [7].		RFC1035 [7].
	ORDER		ORDER
	A 16-bit unsigned integer specifying the order in which the NAPTR		A 16-bit unsigned integer specifying the order in which the NAPTR
	records MUST be processed in order to accurately represent the		records MUST be processed in order to accurately represent the
	ordered list of Rules. The ordering is from lowest to highest.		ordered list of Rules. The ordering is from lowest to highest.
	If two records have the same order value then they are considered		If two records have the same order value then they are considered
	to be the same rule and should be selected randomly unless the		to be the same rule and should be selected based on the
	Preference numbers are different which means the randomization is		combination of the Preference values and Services offered.
	weighted according to the ratio of the Preference values.
	PREFERENCE		PREFERENCE
	Although it is called "preference" in deference to DNS		Although it is called "preference" in deference to DNS
	terminology, this field is equivalent to the Priority value in the		terminology, this field is equivalent to the Priority value in the
	DDDS Algorithm. It is a 16-bit unsigned integer that specifies		DDDS Algorithm. It is a 16-bit unsigned integer that specifies
	the order in which NAPTR records with equal Order values SHOULD be		the order in which NAPTR records with equal Order values SHOULD be
	processed, low numbers being processed before high numbers. This		processed, low numbers being processed before high numbers. This
	is similar to the preference field in an MX record, and is used so		is similar to the preference field in an MX record, and is used so
	domain administrators can direct clients towards more capable		domain administrators can direct clients towards more capable
	hosts or lighter weight protocols. A client MAY look at records		hosts or lighter weight protocols. A client MAY look at records
	with higher preference values if it has a good reason to do so		with higher preference values if it has a good reason to do so
	such as not understanding some protocol or service.		such as not supporting some protocol or service very well.
	The important difference between Order and Preference is that once		The important difference between Order and Preference is that once
	a match is found the client MUST NOT consider records with a		a match is found the client MUST NOT consider records with a
	different Order but they MAY process records with the same Order		different Order but they MAY process records with the same Order
	but different Preferences. I.e. Preference is used to give		but different Preferences. The only exception to this is noted in
	weight to rules that are considered the same from an authority		the second important Note in the DDDS algorithm specification
	standpoint but not from a simple load balancing standpoint.		concerning allowing clients to use more complex Service
			determination between steps 3 and 4 in the algorithm. Preference
			is used to give communicate a higher quality of service to rules
			that are considered the same from an authority standpoint but not
			from a simple load balancing standpoint.
			It is important to note that DNS contains several load balancing
			mechanisms and if load balancing among otherwise equal services
			should be needed then methods such as SRV records or multiple A
			records should be utilized to accomplish load balancing.
	FLAGS		FLAGS
	A <character-string> containing flags to control aspects of the		A <character-string> containing flags to control aspects of the
	rewriting and interpretation of the fields in the record. Flags		rewriting and interpretation of the fields in the record. Flags
	are single characters from the set A-Z and 0-9. The case of the		are single characters from the set A-Z and 0-9. The case of the
	alphabetic characters is not significant. The field can be empty.		alphabetic characters is not significant. The field can be empty.
	It is up to the Application specifying how it is using this		It is up to the Application specifying how it is using this
	Database to define the Flags in this field. It must define which		Database to define the Flags in this field. It must define which
	ones are terminal and which ones are not.		ones are terminal and which ones are not.
	skipping to change at page 8, line 50		skipping to change at page 9, line 11
	tempting in some applications but experience has shown such use to		tempting in some applications but experience has shown such use to
	be extremely fault sensitive, very error prone, and extremely		be extremely fault sensitive, very error prone, and extremely
	difficult to debug.		difficult to debug.
	REPLACEMENT		REPLACEMENT
	A <domain-name> which is the next domain-name to query for		A <domain-name> which is the next domain-name to query for
	depending on the potential values found in the flags field. This		depending on the potential values found in the flags field. This
	field is used when the regular expression is a simple replacement		field is used when the regular expression is a simple replacement
	operation. Any value in this field MUST be a fully qualified		operation. Any value in this field MUST be a fully qualified
	domain-name. Name compression is not to be used for this field.		domain-name. Name compression is not to be used for this field.
	This field and the REGEXP field together make up the Substitution		This field and the REGEXP field together make up the Substitution
	Expression in the DDDS Algorithm. They are also mutually		Expression in the DDDS Algorithm. It is simply a historical
	exclusive. If a record is returned that has values for both		optimization specifically for DNS compression that this field
	fields then it is considered to be in error and should be ignored.		exists. The fields are also mutually exclusive. If a record is
			returned that has values for both fields then it is considered to
			be in error and SHOULD be either ignored or an error returned.
	4.2 Additional Information Processing		4.2 Additional Information Processing
	Additional section processing requires upgraded DNS servers, thus it		Additional section processing requires upgraded DNS servers, thus it
	will take many years before applications can expect to see relevant		will take many years before applications can expect to see relevant
	records in the additional information section.		records in the additional information section.
	4.2.1 Additional Section processing by DNS servers		4.2.1 Additional Section processing by DNS servers
	DNS servers MAY add RRsets to the additional information section that		DNS servers MAY add RRsets to the additional information section that
	skipping to change at page 9, line 36		skipping to change at page 9, line 48
	of handling responses from nameservers that never fill in the		of handling responses from nameservers that never fill in the
	Additional Information part of a response.		Additional Information part of a response.
	4.3 Master File Format		4.3 Master File Format
	The master file format follows the standard rules in RFC-1035. Order		The master file format follows the standard rules in RFC-1035. Order
	and preference, being 16-bit unsigned integers, shall be an integer		and preference, being 16-bit unsigned integers, shall be an integer
	between 0 and 65535. The Flags and Services and Regexp fields are		between 0 and 65535. The Flags and Services and Regexp fields are
	all quoted <character-string>s. Since the Regexp field can contain		all quoted <character-string>s. Since the Regexp field can contain
	numerous backslashes and thus should be treated with care. See		numerous backslashes and thus should be treated with care. See
	Section 10 for how to correctly enter and escape the regular		Section 7 for how to correctly enter and escape the regular
	expression.		expression.
	5. Application Specifications		5. Application Specifications
	This DDDS Database is usable by any application that makes use of the		This DDDS Database is usable by any application that makes use of the
	DDDS algorithm. In addition to the items required to specify a DDDS		DDDS algorithm. In addition to the items required to specify a DDDS
	Application, an application wishing to use this Database must also		Application, an application wishing to use this Database must also
	define the following values:		define the following values:
	o What domain the Key that is produced by the First Well Known Rule		o What domain the Key that is produced by the First Well Known Rule
	skipping to change at page 12, line 34		skipping to change at page 12, line 34
	character, literal occurances of a backslash must be escaped by		character, literal occurances of a backslash must be escaped by
	another backslash. For the case of the cid.urn.arpa record above,		another backslash. For the case of the cid.urn.arpa record above,
	the regular expression entered into the master file should be		the regular expression entered into the master file should be
	"!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually		"!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually
	receives the record, the pattern will have been converted to		receives the record, the pattern will have been converted to
	"!urn:cid:.+@([^\.]+\.)(.*)$!\2!i".		"!urn:cid:.+@([^\.]+\.)(.*)$!\2!i".
	6.2 E164 Example		6.2 E164 Example
	The ENUM Working Group in the IETF has specified a service that		The ENUM Working Group in the IETF has specified a service that
	allows a telephone number to be mapped to a URI. The Application		allows a telephone number to be mapped to a URI [18]. The
	Unique String for the ENUM Application is the E.164 telephone number		Application Unique String for the ENUM Application is the E.164
	with the dashes removed. The First Well Known Rule is to remove all		telephone number with the dashes removed. The First Well Known Rule
	characters from the the telephone number and then use the entire		is to remove all characters from the the telephone number and then
	number as the first Key. For example, the phone number "770-555-		use the entire number as the first Key. For example, the phone
	1212" represented as an E.164 number would be "+1-770-555-1212".		number "770-555-1212" represented as an E.164 number would be "+1-
	Converted to the Key it would be "17705551212".		770-555-1212". Converted to the Key it would be "17705551212".
	The ENUM Application at present only uses this Database. It		The ENUM Application at present only uses this Database. It
	specifies that, in order to convert the first Key into a form valid		specifies that, in order to convert the first Key into a form valid
	for this Database, periods are inserted between each digit, the		for this Database, periods are inserted between each digit, the
	entire Key is inverted and then "e164.arpa" is appended to the end.		entire Key is inverted and then "e164.arpa" is appended to the end.
	The above telephone number would then read		The above telephone number would then read
	"2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to		"2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to
	retrieve Rewrite Rules as NAPTR records.		retrieve Rewrite Rules as NAPTR records.
	For this example telephone number we might get back the following		For this example telephone number we might get back the following
	NAPTR records:		NAPTR records:
	$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.		$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
	IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" .		IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" .
	IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .		IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .
	ENUM uses the same 'u' flag as the URI Resolution Application. This		Both the ENUM [18] and URI Resolution [4] Applications use the 'u'
	flag states that the Rule is terminal and that the output is a URL		flag. This flag states that the Rule is terminal and that the output
	which contains the information needed to contact that telephone		is a URI which contains the information needed to contact that
	service. ENUM also uses the same format for its Service Parameters.		telephone service. ENUM also uses the same format for its Service
	These state that the available protocols used to access that		Parameters. These state that the available protocols used to access
	telephone's service are either the Session Initiation Protocol or		that telephone's service are either the Session Initiation Protocol
	SMTP mail.		or SMTP mail.
	7. Advice for DNS Administrators		7. Advice for DNS Administrators
	Beware of regular expressions. Not only are they difficult to get		Beware of regular expressions. Not only are they difficult to get
	correct on their own, but there is the previously mentioned		correct on their own, but there is the previously mentioned
	interaction with DNS. Any backslashes in a regexp must be entered		interaction with DNS. Any backslashes in a regexp must be entered
	twice in a zone file in order to appear once in a query response.		twice in a zone file in order to appear once in a query response.
	More seriously, the need for double backslashes has probably not been		More seriously, the need for double backslashes has probably not been
	tested by all implementors of DNS servers.		tested by all implementors of DNS servers.
	In order to mitigate zone file problems, administrators should		In order to mitigate zone file problems, administrators should
	encourage those writing rewrite rules to utilize the 'default		encourage those writing rewrite rules to utilize the 'default
	delimiter' feature of the regular expression. In the DDDS		delimiter' feature of the regular expression. In the DDDS
	specification the regular expression starts with the character that		specification the regular expression starts with the character that
	is to be the delimiter. Hence if the first character of the regular		is to be the delimiter. Hence if the first character of the regular
	expression is an exclamation mark ('!') for example then the regular		expression is an exclamation mark ('!') for example then the regular
	expression can usually be written without any backslashes.		expression can usually be written with fewer backslashes.
	8. Notes		8. Notes
	A client MUST process multiple NAPTR records in the order		A client MUST process multiple NAPTR records in the order
	specified by the "order" field, it MUST NOT simply use the first		specified by the "order" field, it MUST NOT simply use the first
	record that provides a known Service Parameter combination.		record that provides a known Service Parameter combination.
	When multiple RRs have the same "order" and all other criteria		When multiple RRs have the same "order" and all other criteria
	being equal, the client should use the value of the preference		being equal, the client should use the value of the preference
	field to select the next NAPTR to consider. However, because it		field to select the next NAPTR to consider. However, because it
	skipping to change at page 18, line 9		skipping to change at page 18, line 9
	resolvable before, this may or may not be considered a problem.		resolvable before, this may or may not be considered a problem.
	Regular expressions should be checked for sanity, not blindly passed		Regular expressions should be checked for sanity, not blindly passed
	to something like PERL since arbitrary code can be included and		to something like PERL since arbitrary code can be included and
	subsequently processed.		subsequently processed.
	References		References
	[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
	One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-		One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-
	urn-ddds-toc-00.txt (work in progress), October 2001.		urn-ddds-toc-02.txt (work in progress), February 2002.
	[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
	Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work		Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work
	in progress), May 2000.		in progress), February 2002.
	[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
	Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-		Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-
	database-07.txt (work in progress), May 2000.		database-07.txt (work in progress), February 2002.
	[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
	Four: The URI Resolution Application", RFC YYYY, draft-ietf-		Four: The URI Resolution Application", RFC YYYY, draft-ietf-
	urn-uri-res-ddds-05.txt (work in progress), October 2000.		urn-uri-res-ddds-06.txt (work in progress), February 2002.
	[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
	Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-		Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-
	urn-net-procedures-09.txt (work in progress), October 2001.		urn-net-procedures-10.txt (work in progress), February 2002.
	[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, BCP 14, March 1997.		Levels", RFC 2119, BCP 14, March 1997.
	[7] Mockapetris, P., "Domain names - implementation and		[7] Mockapetris, P., "Domain names - implementation and
	specification", RFC 1035, STD 13, Nov 1987.		specification", RFC 1035, STD 13, Nov 1987.
	[8] Mockapetris, P., "Domain names - concepts and facilities", RFC		[8] Mockapetris, P., "Domain names - concepts and facilities", RFC
	1034, STD 13, Nov 1987.		1034, STD 13, Nov 1987.
	skipping to change at page 19, line 16		skipping to change at page 19, line 16
	[15] Sollins, K., "Architectural Principles of Uniform Resource Name		[15] Sollins, K., "Architectural Principles of Uniform Resource Name
	Resolution", RFC 2276, January 1998.		Resolution", RFC 2276, January 1998.
	[16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource		[16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
	Identifiers using the Domain Name System", RFC 2168, June 1997.		Identifiers using the Domain Name System", RFC 2168, June 1997.
	[17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC		[17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
	2279, January 1998.		2279, January 1998.
			[18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
			2000.
	Author's Address		Author's Address
	Michael Mealling		Michael Mealling
	VeriSign		VeriSign
	505 Huntmar Park Drive		21345 Ridgetop Circle
	Herndon, VA 22070		Sterling, VA 20166
	US		US
	Phone: +1 770 921-2251		EMail: michael@neonym.net
	EMail: michael@research.netsol.com		URI: http://www.verisignlabs.com
	URI: http://www.verisign.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 23 change blocks.
	46 lines changed or deleted		59 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/