draft-ietf-dnsext-iana-dns-00.txt		rfc2929.txt
	INTERNET-DRAFT Donald E. Eastlake 3rd		Network Working Group D. Eastlake, 3rd
	Eric Brunner		Request for Comments: 2929 Motorola
	Bill Manning		BCP: 42 E. Brunner-Williams
	Expires: June 2000 February 2000		Category: Best Current Practice Engage
			B. Manning
			ISI
			September 2000
	Domain Name System (DNS) IANA Considerations		Domain Name System (DNS) IANA Considerations
	------ ---- ------ ----- ---- --------------
	Status of This Document
	Distribution of this draft <draft-ietf-dnsext-iana-dns-00.txt>, which		Status of this Memo
	is intended to become a Best Current Practice, is unlimited. Comments
	should be sent to the DNS Working Group mailing list
	<namedroppers@internic.net> or to the authors.
	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.
	Internet-Drafts are draft documents valid for a maximum of six		This document specifies an Internet Best Current Practices for the
	months. Internet-Drafts may be updated, replaced, or obsoleted by		Internet Community, and requests discussion and suggestions for
	other documents at any time. It is not appropriate to use Internet-		improvements. Distribution of this memo is unlimited.
	Drafts as reference material or to cite them other than as a
	``working draft'' or ``work in progress.''
	The list of current Internet-Drafts can be accessed at		Copyright Notice
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		Copyright (C) The Internet Society (2000). All Rights Reserved.
	http://www.ietf.org/shadow.html.
	Abstract		Abstract
	Internet Assigned Number Authority (IANA) parameter assignment		Internet Assigned Number Authority (IANA) parameter assignment
	considerations are given for the allocation of Domain Name System		considerations are given for the allocation of Domain Name System
	(DNS) classes, RR types, operation codes, error codes, etc.		(DNS) classes, Resource Record (RR) types, operation codes, error
			codes, etc.
	Table of Contents		Table of Contents
	Status of This Document....................................1		1. Introduction................................................. 2
	Abstract...................................................1		2. DNS Query/Response Headers................................... 2
			2.1 One Spare Bit?.............................................. 3
	Table of Contents..........................................2		2.2 Opcode Assignment........................................... 3
			2.3 RCODE Assignment............................................ 4
	1. Introduction............................................3		3. DNS Resource Records......................................... 5
	2. DNS Query/Response Headers..............................3		3.1 RR TYPE IANA Considerations................................. 6
	2.1 One Spare Bit?.........................................4		3.1.1 Special Note on the OPT RR................................ 7
	2.2 Opcode Assignment......................................4		3.2 RR CLASS IANA Considerations................................ 7
	2.3 RCODE Assignment.......................................5		3.3 RR NAME Considerations...................................... 8
	3. DNS Resource Records....................................5		4. Security Considerations...................................... 9
	3.1 RR TYPE IANA Considerations............................7		References...................................................... 9
	3.1.1 Special Note on the OPT RR...........................8		Authors' Addresses.............................................. 11
	3.2 RR CLASS IANA Considerations...........................8		Full Copyright Statement........................................ 12
	3.3 RR NAME Considerations.................................9
	4. Designated Expert......................................10
	5. Security Considerations................................10
	References................................................10
	Authors Addresses.........................................12
	Expiration and File Name..................................12
	1. Introduction		1. Introduction
	The Domain Name System (DNS) provides replicated distributed secure		The Domain Name System (DNS) provides replicated distributed secure
	hierarchical databases which hierarchically store "resource records"		hierarchical databases which hierarchically store "resource records"
	(RRs) under domain names.		(RRs) under domain names.
	This data is structured into CLASSes and zones which can be		This data is structured into CLASSes and zones which can be
	independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]		independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]
	familiarity with which is assumed.		familiarity with which is assumed.
	This document covers, either directly or by reference, general IANA		This document covers, either directly or by reference, general IANA
	parameter assignment considerations applying across DNS query and		parameter assignment considerations applying across DNS query and
	response headers and all RRs. There may be additional IANA		response headers and all RRs. There may be additional IANA
	considerations that apply to only a particular RR type or		considerations that apply to only a particular RR type or
	query/response opcode. See the specific RFC defining that RR type or		query/response opcode. See the specific RFC defining that RR type or
	query/response opcode for such considerations if they have been		query/response opcode for such considerations if they have been
	defined.		defined.
	IANA currently maintains a web page of DNS parameters at		IANA currently maintains a web page of DNS parameters. See
	<http://www.isi.edu/in-notes/iana/assignments/dns-parameters>.		<http://www.iana.org/numbers.htm>.
	"IETF Standards Action", "IETF Consensus", "Specification Required",		"IETF Standards Action", "IETF Consensus", "Specification Required",
	and "Private Use" are as defined in [RFC 2434].		and "Private Use" are as defined in [RFC 2434].
	2. DNS Query/Response Headers		2. DNS Query/Response Headers
	The header for DNS queries and responses contains field/bits in the		The header for DNS queries and responses contains field/bits in the
	following diagram taken from [RFC 2136, 2535]:		following diagram taken from [RFC 2136, 2535]:
	1 1 1 1 1 1		1 1 1 1 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| ID |		| ID |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |		|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| QDCOUNT/ZOCOUNT |		| QDCOUNT/ZOCOUNT |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| ANCOUNT/PRCOUNT |		| ANCOUNT/PRCOUNT |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| NSCOUNT/UPCOUNT |		| NSCOUNT/UPCOUNT |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| ARCOUNT |		| ARCOUNT |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	The ID field identifies the query and is echoed in the response so		The ID field identifies the query and is echoed in the response so
	they can be matched.		they can be matched.
	The QR bit indicates whether the header is for a query or a response.		The QR bit indicates whether the header is for a query or a response.
	The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful		The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
	only in queries or only in responses, depending on the bit. However,		only in queries or only in responses, depending on the bit. However,
	many DNS implementations copy the query header as the initial value		many DNS implementations copy the query header as the initial value
	of the response header without clearing bits. Thus any attempt to		of the response header without clearing bits. Thus any attempt to
	skipping to change at page 4, line 39		skipping to change at page 3, line 39
	implementations ignore this bit.		implementations ignore this bit.
	Assigning a meaning to the Z bit requires an IETF Standards Action.		Assigning a meaning to the Z bit requires an IETF Standards Action.
	2.2 Opcode Assignment		2.2 Opcode Assignment
	New OpCode assignments require an IETF Standards Action.		New OpCode assignments require an IETF Standards Action.
	Currently DNS OpCodes are assigned as follows:		Currently DNS OpCodes are assigned as follows:
	OpCode Name Reference		OpCode Name Reference
	0 Query [RFC 1035]		0 Query [RFC 1035]
	1 IQuery (Inverse Query) [RFC 1035]		1 IQuery (Inverse Query) [RFC 1035]
	2 Status [RFC 1035]		2 Status [RFC 1035]
	3 available for assignment		3 available for assignment
	4 Notify [RFC 1996]		4 Notify [RFC 1996]
	5 Update [RFC 2136]		5 Update [RFC 2136]
	6-15 available for assignment		6-15 available for assignment
	2.3 RCODE Assignment		2.3 RCODE Assignment
	It would appear from the DNS header above that only four bits of		It would appear from the DNS header above that only four bits of
	RCODE, or response/error code are available. However, RCODEs can		RCODE, or response/error code are available. However, RCODEs can
	appear not only at the top level of a DNS response but also inside		appear not only at the top level of a DNS response but also inside
	TSIG RRs [RFC XXX3] and OPT RRs [RFC 2671]. The OPT RR provides an		OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
	eight bit extension resulting in a 12 bit RCODE field and the TSIG RR		The OPT RR provides an eight bit extension resulting in a 12 bit
	has a 16 bit RCODE field.		RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
	RCODE Name Description Reference		Error codes appearing in the DNS header and in these three RR types
	Decimal		all refer to the same error code space with the single exception of
	Hexadecimal		error code 16 which has a different meaning in the OPT RR from its
	0 NoError No Error [RFC 1035]		meaning in other contexts. See table below.
	1 FormErr Format Error [RFC 1035]
	2 ServFail Server Failure [RFC 1035]		RCODE Name Description Reference
	3 NXDomain Non-Existent Domain [RFC 1035]		Decimal
	4 NotImp Not Implemented [RFC 1035]		Hexadecimal
	5 Refused Query Refused [RFC 1035]		0 NoError No Error [RFC 1035]
	6 YXDomain Name Exists when it should not [RFC 2136]		1 FormErr Format Error [RFC 1035]
	7 YXRRSet RR Set Exists when it should not [RFC 2136]		2 ServFail Server Failure [RFC 1035]
	8 NXRRSet RR Set that should exist does not [RFC 2136]		3 NXDomain Non-Existent Domain [RFC 1035]
	9 NotAuth Server Not Authoritative for zone [RFC 2136]		4 NotImp Not Implemented [RFC 1035]
	10 NotZone Name not contained in zone [RFC 2136]		5 Refused Query Refused [RFC 1035]
	11-15 available for assignment		6 YXDomain Name Exists when it should not [RFC 2136]
	16 BADVERS Bad OPT Version [RFC 2671]		7 YXRRSet RR Set Exists when it should not [RFC 2136]
	16 BADSIG TSIG Signature Failure [RFC XXX3]		8 NXRRSet RR Set that should exist does not [RFC 2136]
	17 BADKEY Key not recognized [RFC XXX3]		9 NotAuth Server Not Authoritative for zone [RFC 2136]
	18 BADTIME Signature out of time window [RFC XXX3]		10 NotZone Name not contained in zone [RFC 2136]
	19-3840 available for assignment		11-15 available for assignment
	0x0013-0x0F00		16 BADVERS Bad OPT Version [RFC 2671]
	3841-4095 Private Use		16 BADSIG TSIG Signature Failure [RFC 2845]
	0x0F01-0x0FFF		17 BADKEY Key not recognized [RFC 2845]
	4096-65535 available for assignment		18 BADTIME Signature out of time window [RFC 2845]
	0x1000-0xFFFF		19 BADMODE Bad TKEY Mode [RFC 2930]
			20 BADNAME Duplicate key name [RFC 2930]
			21 BADALG Algorithm not supported [RFC 2930]
			22-3840 available for assignment
			0x0016-0x0F00
			3841-4095 Private Use
			0x0F01-0x0FFF
			4096-65535 available for assignment
			0x1000-0xFFFF
	Since it is important that RCODEs be understood for interoperability,		Since it is important that RCODEs be understood for interoperability,
	assignment of new RCODE listed above as "available for assignment"		assignment of new RCODE listed above as "available for assignment"
	requires an IETF Consensus.		requires an IETF Consensus.
	3. DNS Resource Records		3. DNS Resource Records
	All RRs have the same top level format shown in the figure below		All RRs have the same top level format shown in the figure below
	taken from [RFC 1035]:		taken from [RFC 1035]:
	1 1 1 1 1 1		1 1 1 1 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |		| |
	/ /		/ /
	/ NAME /		/ NAME /
	| |		| |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| TYPE |		| TYPE |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| CLASS |		| CLASS |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| TTL |		| TTL |
	| |		| |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| RDLENGTH |		| RDLENGTH |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
	/ RDATA /		/ RDATA /
	/ /		/ /
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	NAME is an owner name, i.e., the name of the node to which this		NAME is an owner name, i.e., the name of the node to which this
	resource record pertains. NAMEs are specific to a CLASS as described		resource record pertains. NAMEs are specific to a CLASS as described
	in section 3.2. NAMEs consist of an ordered sequence of one or more		in section 3.2. NAMEs consist of an ordered sequence of one or more
	labels each of which has a label type [RFC 1035, 2671].		labels each of which has a label type [RFC 1035, 2671].
	TYPE is a two octet unsigned integer containing one of the RR TYPE		TYPE is a two octet unsigned integer containing one of the RR TYPE
	codes. See section 3.1.		codes. See section 3.1.
	CLASS is a two octet unsigned integer containing one of the RR CLASS		CLASS is a two octet unsigned integer containing one of the RR CLASS
	skipping to change at page 7, line 21		skipping to change at page 6, line 25
	used in queries. Meta-TYPEs designate transient data associated with		used in queries. Meta-TYPEs designate transient data associated with
	an particular DNS message and in some cases can also be used in		an particular DNS message and in some cases can also be used in
	queries. Thus far, data TYPEs have been assigned from 1 upwards plus		queries. Thus far, data TYPEs have been assigned from 1 upwards plus
	the block from 100 through 103 while Q and Meta Types have been		the block from 100 through 103 while Q and Meta Types have been
	assigned from 255 downwards (except for the OPT Meta-RR which is		assigned from 255 downwards (except for the OPT Meta-RR which is
	assigned TYPE 41). There have been DNS implementations which made		assigned TYPE 41). There have been DNS implementations which made
	caching decisions based on the top bit of the bottom byte of the RR		caching decisions based on the top bit of the bottom byte of the RR
	TYPE.		TYPE.
	There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG		There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
	[RFC XXX3], and TKEY [work in progress].		[RFC 2845], and TKEY [RFC 2930].
	There are currently five QTYPEs assigned: * (all), MAILA, MAILB,		There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
	AXFR, and IXFR.		AXFR, and IXFR.
	Considerations for the allocation of new RR TYPEs are as follows:		Considerations for the allocation of new RR TYPEs are as follows:
	Decimal		Decimal
	Hexadecimal		Hexadecimal
	0		0
	skipping to change at page 8, line 9		skipping to change at page 7, line 15
	32768 - 65279		32768 - 65279
	0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].		0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
	65280 - 65535		65280 - 65535
	0xFF00 - 0xFFFF - Private Use.		0xFF00 - 0xFFFF - Private Use.
	3.1.1 Special Note on the OPT RR		3.1.1 Special Note on the OPT RR
	The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its		The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
	primary purpose is to extend the effective field size of various DNS		primary purpose is to extend the effective field size of various DNS
	fields including RCODE, label type, OpCode, flag bits, and RDATA		fields including RCODE, label type, flag bits, and RDATA size. In
	size. In particular, for resolvers and servers that recognize it, it		particular, for resolvers and servers that recognize it, it extends
	extends the RCODE field from 4 to 12 bits.		the RCODE field from 4 to 12 bits.
	3.2 RR CLASS IANA Considerations		3.2 RR CLASS IANA Considerations
	DNS CLASSes have been little used but constitute another dimension of		DNS CLASSes have been little used but constitute another dimension of
	the DNS distributed database. In particular, there is no necessary		the DNS distributed database. In particular, there is no necessary
	relationship between the name space or root servers for one CLASS and		relationship between the name space or root servers for one CLASS and
	those for another CLASS. The same name can have completely different		those for another CLASS. The same name can have completely different
	meanings in different CLASSes although the label types are the same		meanings in different CLASSes although the label types are the same
	and the null label is usable only as root in every CLASS. However,		and the null label is usable only as root in every CLASS. However,
	as global networking and DNS have evolved, the IN, or Internet, CLASS		as global networking and DNS have evolved, the IN, or Internet, CLASS
	skipping to change at page 8, line 43		skipping to change at page 7, line 49
	0		0
	0x0000 - assignment requires an IETF Standards Action.		0x0000 - assignment requires an IETF Standards Action.
	1		1
	0x0001 - Internet (IN).		0x0001 - Internet (IN).
	2		2
	0x0002 - available for assignment by IETF Consensus as a data CLASS.		0x0002 - available for assignment by IETF Consensus as a data CLASS.
	3		3
	0x0003 - Chaos (CH) [Moon 81].		0x0003 - Chaos (CH) [Moon 1981].
	4		4
	0x0004 - Hesiod (HS) [Dyer 87].		0x0004 - Hesiod (HS) [Dyer 1987].
	5 - 127		5 - 127
	0x0005 - 0x007F - available for assignment by IETF Consensus as data		0x0005 - 0x007F - available for assignment by IETF Consensus as data
	CLASSes only.		CLASSes only.
	128 - 253		128 - 253
	0x0080 - 0x00FD - available for assignment by IETF Consensus as		0x0080 - 0x00FD - available for assignment by IETF Consensus as
	QCLASSes only.		QCLASSes only.
	254		254
	skipping to change at page 9, line 38		skipping to change at page 8, line 42
	3.3 RR NAME Considerations		3.3 RR NAME Considerations
	DNS NAMEs are sequences of labels [RFC 1035]. The last label in each		DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
	NAME is "ROOT" which is the zero length label. By definition, the		NAME is "ROOT" which is the zero length label. By definition, the
	null or ROOT label can not be used for any other NAME purpose.		null or ROOT label can not be used for any other NAME purpose.
	At the present time, there are two categories of label types, data		At the present time, there are two categories of label types, data
	labels and compression labels. Compression labels are pointers to		labels and compression labels. Compression labels are pointers to
	data labels elsewhere within an RR or DNS message and are intended to		data labels elsewhere within an RR or DNS message and are intended to
	shorten the wire encoding of NAMEs. The two existing data label		shorten the wire encoding of NAMEs. The two existing data label
	types are frequently referred to as ASCII and Binary. ASCII labels		types are sometimes referred to as Text and Binary. Text labels can,
	can, in fact, include any octet value including zero octets but most		in fact, include any octet value including zero octets but most
	current uses involve only [US-ASCII] For retrieval ASCII labels are		current uses involve only [US-ASCII]. For retrieval, Text labels are
	defined to treat upper and lower case letters the same. Binary		defined to treat ASCII upper and lower case letter codes as matching.
	labels are bit sequences [RFC 2673].		Binary labels are bit sequences [RFC 2673].
	IANA considerations for label types are given in [RFC 2671].		IANA considerations for label types are given in [RFC 2671].
	NAMEs are local to a CLASS. The Hesiod [Dyer 87] and Chaos [Moon 81]		NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
	CLASSes are essentially for local use. The IN or Internet CLASS is		1981] CLASSes are essentially for local use. The IN or Internet
	thus the only DNS CLASS in global use on the Internet at this time.		CLASS is thus the only DNS CLASS in global use on the Internet at
			this time.
	A somewhat dated description of name allocation in the IN Class is		A somewhat dated description of name allocation in the IN Class is
	given in [RFC 1591]. Some information on reserved top level domain		given in [RFC 1591]. Some information on reserved top level domain
	names is in Best Current Practice 32 [RFC 2606].		names is in Best Current Practice 32 [RFC 2606].
	4. Designated Expert		4. Security Considerations
	To provide additional support to IANA in the DNS area, the IESG MAY
	appoint a designed expert.
	5. Security Considerations
	This document addresses IANA considerations in the allocation of		This document addresses IANA considerations in the allocation of
	general DNS parameters, not security. See [RFC 2535] for secure DNS		general DNS parameters, not security. See [RFC 2535] for secure DNS
	considerations.		considerations.
	References		References
	[Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical		[Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
	Plan - Name Service, April 1987,		Plan - Name Service, April 1987,
	[Moon 81] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts		[Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
	Institute of Technology Artificial Intelligence Laboratory, June		Institute of Technology Artificial Intelligence
	1981.		Laboratory, June 1981.
	[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and		[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
	Facilities", STD 13, November 1987.		Facilities", STD 13, RFC 1034, November 1987.
	[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and		[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
	Specifications", STD 13, November 1987.		Specifications", STD 13, RFC 1035, November 1987.
	[RFC 1591] - J. Postel, "Domain Name System Structure and		[RFC 1591] Postel, J., "Domain Name System Structure and
	Delegation", March 1994.		Delegation", RFC 1591, March 1994.
	[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone		[RFC 1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
	Changes (DNS NOTIFY)", August 1996.		Changes (DNS NOTIFY)", RFC 1996, August 1996.
	[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic		[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
	Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.		"Dynamic Updates in the Domain Name System (DNS UPDATE)",
			RFC 2136, April 1997.
	[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS		[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS
	Specification", July 1997.		Specification", RFC 2181, July 1997.
	[RFC 2434] - "Guidelines for Writing an IANA Considerations Section		[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	in RFCs", T. Narten, H. Alvestrand, October 1998.		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
			October 1998.
	[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",		[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
	March 1999.		RFC 2535, March 1999.
	[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",		[RFC 2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
	June 1999.		Names", RFC 2606, June 1999.
	[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August		[RFC 2671] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
	1999.		2671, August 1999.
	[RFC 2672] - M. Crawford, " Non-Terminal DNS Name Redirection",		[RFC 2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
	August 1999.		2672, August 1999.
	[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",		[RFC 2673] Crawford, M., "Binary Labels in the Domain Name System",
	August 1999.		RFC 2673, August 1999.
	[RFC XXX3] - P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,		[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
	"Secret Key Transaction Signatures for DNS (TSIG)", xxx 2000 (draft-		Wellington, "Secret Key Transaction Authentication for
	ietf-dnsind-tsig-*.txt).		DNS (TSIG)", RFC 2845, May 2000.
	[US-ASCII] - ANSI, "USA Standard Code for Information		[RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
	Interchange", X3.4, American National Standards Institute: New York,		RR)", RFC 2930, September 2000.
	1968.
	Authors Addresses		[US-ASCII] ANSI, "USA Standard Code for Information Interchange",
			X3.4, American National Standards Institute: New York,
			1968.
			Authors' Addresses
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Motorola		Motorola
	65 Shindegan Hill Road		140 Forest Avenue
	Carmel, NY 10512 USA		Hudson, MA 01749 USA
	Telephone: +1-914-276-2668 (h)		Phone: +1-978-562-2827 (h)
	+1-508-261-5434 (w)		+1-508-261-5434 (w)
	email: dee3@torque.pothole.com		Fax: +1-508-261-4447 (w)
			EMail: Donald.Eastlake@motorola.com
	Eric Brunner		Eric Brunner-Williams
	1415 Forest Avenue		Engage
	Portland, ME 04103 USA		100 Brickstone Square, 2nd Floor
			Andover, MA 01810
	Telephone: +1 207-797-0525		Phone: +1-207-797-0525 (h)
	email: brunner@world.std.com		+1-978-684-7796 (w)
			Fax: +1-978-684-3118
			EMail: brunner@engage.com
	Bill Manning		Bill Manning
	USC/ISI		USC/ISI
	4676 Admiralty Way, #1001		4676 Admiralty Way, #1001
	Marina del Rey, CA 90292 USA		Marina del Rey, CA 90292 USA
	Telephone: +1 310 822 1511		Phone: +1-310-822-1511
	email: bmanning@isi.edu		EMail: bmanning@isi.edu
	Expiration and File Name		Full Copyright Statement
	This draft expires August 2000.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	Its file name is draft-ietf-dnsext-iana-dns-00.txt.		This document and translations of it may be copied and furnished to
			others, and derivative works that comment on or otherwise explain it
			or assist in its implementation may be prepared, copied, published
			and distributed, in whole or in part, without restriction of any
			kind, provided that the above copyright notice and this paragraph are
			included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
			The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assigns.
			This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
			BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
			HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
			MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 47 change blocks.
	191 lines changed or deleted		185 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/