< draft-ietf-dnsext-dnssec-records-03.txt		draft-ietf-dnsext-dnssec-records-04.txt >
	DNS Extensions R. Arends		DNS Extensions R. Arends
	Internet-Draft Telematica Instituut		Internet-Draft Telematica Instituut
	Expires: August 26, 2003 R. Austein		Expires: March 16, 2004 R. Austein
	ISC		ISC
	M. Larson		M. Larson
	VeriSign		VeriSign
	D. Massey		D. Massey
	USC/ISI		USC/ISI
	S. Rose		S. Rose
	NIST		NIST
	February 25, 2003		September 16, 2003
	Resource Records for the DNS Security Extensions		Resource Records for the DNS Security Extensions
	draft-ietf-dnsext-dnssec-records-03		draft-ietf-dnsext-dnssec-records-04
	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
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 August 26, 2003.		This Internet-Draft will expire on March 16, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	This document is part of a family of documents that describes the DNS		This document is part of a family of documents that describes the DNS
	Security Extensions (DNSSEC). The DNS Security Extensions are a		Security Extensions (DNSSEC). The DNS Security Extensions are a
	collection of resource records and protocol modifications that		collection of resource records and protocol modifications that
	provide source authentication for the DNS. This document defines the		provide source authentication for the DNS. This document defines the
	KEY, DS, SIG, and NXT resource records. The purpose and format of		public key (DNSKEY), delegation signer (DS), resource record digital
	each resource record is described in detail and an example of each		signature (RRSIG), and authenticated denial of existance (NSEC)
	resource record is given.		resource records. The purpose and format of each resource record is
			described in detail, and an example of each resource record is given.
			This document obsoletes RFC 2535 and incorporates changes from all
			updates to RFC 2535.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Background and Related Documents . . . . . . . . . . . . . . 4		1.1 Background and Related Documents . . . . . . . . . . . . . . 4
	1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4		1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . . 4		1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4		1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
	1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4		1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
	1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5		1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
	2. The KEY Resource Record . . . . . . . . . . . . . . . . . . 6		2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 6
	2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . . 6		2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6
	2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6		2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7		2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7
	2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7		2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7
	2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7		2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7
	2.1.5 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . . 7		2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . . . . 7
	2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . . 7		2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7
	2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . . 7		2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8
	3. The SIG Resource Record . . . . . . . . . . . . . . . . . . 9		3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9
	3.1 SIG RDATA Wire Format . . . . . . . . . . . . . . . . . . . 9		3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . . 9
	3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10		3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10
	3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10		3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10
	3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10		3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10
	3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11		3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11
	3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11		3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11
	3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11		3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11
	3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11		3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11
	3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12		3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12
	3.2 The SIG RR Presentation Format . . . . . . . . . . . . . . . 12		3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13
	3.3 SIG RR Example . . . . . . . . . . . . . . . . . . . . . . . 13		3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13
	4. The NXT Resource Record . . . . . . . . . . . . . . . . . . 15		4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15
	4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15		4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15
	4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15		4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15
	4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 15		4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 16
	4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . . 16		4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 16
	4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . . 16		4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 16
	4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . . 16		4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17
	5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18		5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18
	5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18		5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18
	5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 18		5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 19
	5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19		5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19
	5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19		5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19
	5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19		5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19
	5.2 The DS RR Presentation Format . . . . . . . . . . . . . . . 19		5.2 Processing of DS RRs When Validating Responses . . . . . . . 19
	5.3 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20		5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 20
			5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20
	6. Canonical Form and Order of Resource Records . . . . . . . . 21		6. Canonical Form and Order of Resource Records . . . . . . . . 21
	6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21		6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21
	6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21		6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21
	6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22		6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
	8. Security Considerations . . . . . . . . . . . . . . . . . . 24		8. Security Considerations . . . . . . . . . . . . . . . . . . 25
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26
	Normative References . . . . . . . . . . . . . . . . . . . . 26		Normative References . . . . . . . . . . . . . . . . . . . . 27
	Informative References . . . . . . . . . . . . . . . . . . . 27		Informative References . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
	A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 29		A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 31
	A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 29		A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 31
	A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 29		A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 31
	A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 30		A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 32
	B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 31		B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 33
	B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 32		B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 34
	Full Copyright Statement . . . . . . . . . . . . . . . . . . 33		Intellectual Property and Copyright Statements . . . . . . . 35
	1. Introduction		1. Introduction
	The DNS Security Extensions (DNSSEC) introduce four new DNS resource		The DNS Security Extensions (DNSSEC) introduce four new DNS resource
	record types: KEY, SIG, NXT, and DS. This document defines the		record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the
	purpose of each resource record (RR), the RR's RDATA format, and its		purpose of each resource record (RR), the RR's RDATA format, and its
	ASCII representation.		ASCII representation.
	1.1 Background and Related Documents		1.1 Background and Related Documents
	The reader is assumed to be familiar with the basic DNS concepts		The reader is assumed to be familiar with the basic DNS concepts
	described in RFC1034 [1] and RFC1035 [2].		described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent
			RFC's that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and
			RFC2308 [RFC2308].
	This document is part of a family of documents that define the DNS		This document is part of a family of documents that define the DNS
	security extensions. The DNS security extensions (DNSSEC) are a		security extensions. The DNS security extensions (DNSSEC) are a
	collection of resource records and DNS protocol modifications that		collection of resource records and DNS protocol modifications that
	add source authentication the Domain Name System (DNS). An		add source authentication and data integrity the Domain Name System
	introduction to DNSSEC and definition of common terms can be found in		(DNS). An introduction to DNSSEC and definition of common terms can
	[10]. A description of DNS protocol modifications can be found in		be found in [I-D.ietf-dnsext-dnssec-intro]. A description of DNS
	[11]. This document defines the DNSSEC resource records.		protocol modifications can be found in
			[I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC
			resource records.
	1.2 Reserved Words		1.2 Reserved Words
	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 this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [5].		document are to be interpreted as described in RFC 2119 [RFC2119].
	1.3 Editors Notes		1.3 Editors' Notes
	1.3.1 Open Technical Issues		1.3.1 Open Technical Issues
	The NXT section (Section 4) may be updated in the next version if
	DNSSEC-Opt-In [13] becomes part of DNSSEC.
	The cryptographic algorithm types (Appendix A) requires input from		The cryptographic algorithm types (Appendix A) requires input from
	the working group. The DSA algorithm was moved to OPTIONAL. This		the working group. The DSA algorithm was moved to OPTIONAL. This
	had strong consensus in workshops and various discussions and a		had strong consensus in workshops and various discussions and a
	separate internet draft solely to move DSA from MANDATORY to OPTIONAL		separate internet draft solely to move DSA from MANDATORY to OPTIONAL
	seemed excessive. This draft solicits input on that proposed change.		seemed excessive. This draft solicits input on that proposed change.
	1.3.2 Technical Changes or Corrections		1.3.2 Technical Changes or Corrections
	Please report technical corrections to dnssec-editors@east.isi.edu.		Please report technical corrections to dnssec-editors@east.isi.edu.
	To assist the editors, please indicate the text in error and point		To assist the editors, please indicate the text in error and point
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	1.3.3 Typos and Minor Corrections		1.3.3 Typos and Minor Corrections
	Please report any typos corrections to dnssec-editors@east.isi.edu.		Please report any typos corrections to dnssec-editors@east.isi.edu.
	To assist the editors, please provide enough context for us to find		To assist the editors, please provide enough context for us to find
	the incorrect text quickly.		the incorrect text quickly.
	An example message to dnssec-editors might be: page X says "the		An example message to dnssec-editors might be: page X says "the
	DNSSEC standard has been in development for over 1 years". It		DNSSEC standard has been in development for over 1 years". It
	should read "over 10 years".		should read "over 10 years".
	2. The KEY Resource Record		2. The DNSKEY Resource Record
	DNSSEC uses public key cryptography to sign and authenticate DNS		DNSSEC uses public key cryptography to sign and authenticate DNS
	resource record sets (RRsets). The public keys are stored in KEY		resource record sets (RRsets). The public keys are stored in DNSKEY
	resource records and are used in the DNSSEC authentication process		resource records and are used in the DNSSEC authentication process
	described in [11]. In a typical example, a zone signs its		described in [I-D.ietf-dnsext-dnssec-protocol]. For example, a zone
	authoritative RRsets using a private key and stores the corresponding		signs its authoritative RRsets using a private key and stores the
	public key in a KEY RR. A resolver can then use these signatures to		corresponding public key in a DNSKEY RR. A resolver can then use
	authenticate RRsets from the zone.		these signatures to authenticate RRsets from the zone.
	The KEY RR may also be used to store public keys associated with		The DNSKEY RR may also be used to store public keys associated with
	other DNS operations such as TKEY [15]. In all cases, the KEY RR		other DNS operations such as TKEY [RFC2930]. The DNSKEY RR is not,
	plays a special role in secure DNS resolution and DNS message		however, intended as a record for storing arbitrary public keys. The
	processing. The KEY RR is not intended as a record for storing		DNSKEY RR MUST NOT be used to store certificates or public keys that
	arbitrary public keys. The KEY RR MUST NOT be used to store		do not directly relate to the DNS infrastructure.
	certificates or public keys that do not directly relate to the DNS
	infrastructure. Examples of certificates and public keys that MUST
	NOT be stored in the KEY RR include X.509 certificates, IPSEC public
	keys, and SSH public keys.
	The Type value for the KEY RR type is 25.		The Type value for the DNSKEY RR type is 48.
	The KEY RR is class independent.		The DNSKEY RR is class independent.
	There are no special TTL requirements on the KEY record.		The DNSKEY RR has no special TTL requirements.
	2.1 KEY RDATA Wire Format		2.1 DNSKEY RDATA Wire Format
	The RDATA for a KEY RR consists of a 2 octet Flags Field, a 1 octet		The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
	Protocol Field, a 1 octet Algorithm Field , and the Public Key Field.		octet Protocol Field, a 1 octet Algorithm Field , and the Public Key
			Field.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Protocol | Algorithm |		| Flags | Protocol | Algorithm |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ /		/ /
	/ Public Key /		/ Public Key /
	/ /		/ /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.1.1 The Flags Field		2.1.1 The Flags Field
	Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,		Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
	then the KEY record holds a DNS zone key and the KEY's owner name		then the DNSKEY record holds a DNS zone key and the DNSKEY's owner
	MUST be the name of a zone. If bit 7 has value 0, then the KEY		name MUST be the name of a zone. If bit 7 has value 0, then the
	record holds some other type of DNS public key, such as a public key		DNSKEY record holds some other type of DNS public key, such as a
	used by TKEY.		public key used by TKEY.
	Bits 0-6 and 8-15 are reserved and MUST have value 0 upon creation of		Bit 15 of the Flags field is the Secure Entry Point flag, described
	the KEY RR, and MUST be ignored upon reception.		in [I-D.ietf-dnsext-keyrr-key-signing-flag]. If bit 15 has value 1,
			then the DNSKEY record holds a key intended for use as a secure entry
			point. This flag is only intended to be to a hint to zone signing or
			debugging software as to the intended use of this DNSKEY record;
			security-aware resolvers MUST NOT alter their behavior during the
			signature validation process in any way based on the setting of this
			bit.
	Editors' Note: draft-ietf-dnsext-keyrr-key-signing-flag changes this		Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
	by allocating bit 15 as the KSK bit.		creation of the DNSKEY RR, and MUST be ignored upon reception.
	2.1.2 The Protocol Field		2.1.2 The Protocol Field
	The Protocol Field MUST have value 3.		The Protocol Field MUST have value 3 and MUST be treated as invalid
			during signature verification if found to be some value other than 3.
	2.1.3 The Algorithm Field		2.1.3 The Algorithm Field
	The Algorithm field identifies the public key's cryptographic		The Algorithm field identifies the public key's cryptographic
	algorithm and determines the format of the Public Key field. A list		algorithm and determines the format of the Public Key field. A list
	of DNSSEC algorithm types can be found in Appendix A.1		of DNSSEC algorithm types can be found in Appendix A.1
	2.1.4 The Public Key Field		2.1.4 The Public Key Field
	The Public Key Field holds the public key material.		The Public Key Field holds the public key material itself.
	2.1.5 Notes on KEY RDATA Design		2.1.5 Notes on DNSKEY RDATA Design
	Although the Protocol Field always has value 3, it is retained for		Although the Protocol Field always has value 3, it is retained for
	backward compatibility with an earlier version of the KEY record.		backward compatibility with early versions of the KEY record.
	2.2 The KEY RR Presentation Format		2.2 The DNSKEY RR Presentation Format
	The presentation format of the RDATA portion is as follows:		The presentation format of the RDATA portion is as follows:
	The Flag field is represented as an unsigned decimal integer with a		The Flag field MUST be represented as an unsigned decimal integer
	value of either 0 or 256.		with a value of 0, 256, or 257.
	The Protocol Field is represented as an unsigned decimal integer with		The Protocol Field MUST be represented as an unsigned decimal integer
	a value of 3.		with a value of 3.
	The Algorithm field is represented either as an unsigned decimal		The Algorithm field MUST be represented either as an unsigned
	integer or as an algorithm mnemonic as specified in Appendix A.1.		decimal integer or as an algorithm mnemonic as specified in Appendix
			A.1.
	The Public Key field is represented as a Base64 encoding of the		The Public Key field MUST be represented as a Base64 encoding of the
	Public Key. Whitespace is allowed within the Base64 text. For a		Public Key. Whitespace is allowed within the Base64 text. For a
	definition of Base64 encoding, see [3] Section 5.2.		definition of Base64 encoding, see [RFC1521] Section 5.2.
	2.3 KEY RR Example		2.3 DNSKEY RR Example
	The following KEY RR stores a DNS zone key for example.com.		The following DNSKEY RR stores a DNS zone key for example.com.
	example.com. 86400 IN KEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3Cbl		example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
	+BBZH4b/0PY1kxkmvHjcZc8nokfzj31		Cbl+BBZH4b/0PY1kxkmvHjcZc8no
	GajIQKY+5CptLr3buXA10hWqTkF7H6R		kfzj31GajIQKY+5CptLr3buXA10h
	foRqXQeogmMHfpftf6zMv1LyBUgia7z		WqTkF7H6RfoRqXQeogmMHfpftf6z
	a6ZEzOJBOztyvhjL742iU/TpPSEDhm2		Mv1LyBUgia7za6ZEzOJBOztyvhjL
	SNKLijfUppn1UaNvv4w== )		742iU/TpPSEDhm2SNKLijfUppn1U
			aNvv4w== )
	The first four text fields specify the owner name, TTL, Class, and RR		The first four text fields specify the owner name, TTL, Class, and RR
	type (KEY). Value 256 indicates that the Zone Key bit (bit 7) in the		type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in
	Flags field has value 1. Value 3 is the fixed Protocol value. Value		the Flags field has value 1. Value 3 is the fixed Protocol value.
	5 indicates the public key algorithm. Appendix A.1 identifies		Value 5 indicates the public key algorithm. Appendix A.1 identifies
	algorithm type 5 as RSA/SHA1 and indicates that the format of the		algorithm type 5 as RSA/SHA1 and indicates that the format of the
	RSA/SHA1 public key field is defined in [8]. The remaining text is a		RSA/SHA1 public key field is defined in [RFC3110]. The remaining
	base 64 encoding of the public key.		text is a Base64 encoding of the public key.
	3. The SIG Resource Record		3. The RRSIG Resource Record
	DNSSEC uses public key cryptography to sign and authenticate DNS		DNSSEC uses public key cryptography to sign and authenticate DNS
	resource record sets (RRsets). Signatures are stored in SIG resource		resource record sets (RRsets). Digital signatures are stored in
	records and are used in the DNSSEC authentication process described		RRSIG resource records and are used in the DNSSEC authentication
	in [11]. In a typical example, a zone signs its authoritative RRsets		process described in [I-D.ietf-dnsext-dnssec-protocol]. A
	using a private key and stores the corresponding signatures in SIG		security-aware resolver can use these RRSIG RRs to authenticate
	RRs. A resolver can then use these SIG RRs to authenticate RRsets		RRsets from the zone. The RRSIG RR MUST only be used to carry
	from the zone.		verification material (digital signatures) used to secure DNS
			operations.
	A SIG record contains the signature for an RRset with a particular		A RRSIG record contains the signature for an RRset with a particular
	name, class, and type. The SIG RR specifies a validity interval for		name, class, and type. The RRSIG RR specifies a validity interval
	the signature and uses the Algorithm, the Signer's Name, and the Key		for the signature and uses the Algorithm, the Signer's Name, and the
	Tag to identify the public key (KEY RR) that can be used to verify		Key Tag to identify the DNSKEY RR containing the public key that a
	the signature.		resolver can use to verify the signature.
	The SIG RR may cover a transaction instead of an RRset. In this		The Type value for the RRSIG RR type is 46.
	case, the "Type Covered" field value is 0, the SIG RR MUST NOT appear
	in any zone, and its use and processing are outside the scope of this
	document. Please see [7] for further details.
	The Type value for the SIG RR type is 24.		The RRSIG RR is class independent.
	The SIG RR MUST have the same class as the RRset it covers.		A RRSIG RR MUST have the same class as the RRset it covers.
	The SIG RR TTL value SHOULD match the TTL value of the RRset it		The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
	covers.		it covers.
	3.1 SIG RDATA Wire Format		3.1 RRSIG RDATA Wire Format
	The RDATA for a SIG RR consists of a 2 octet Type Covered field, a 1		The RDATA for a RRSIG RR consists of a 2 octet Type Covered field, a
	octet Algorithm field, a 1 octet Labels field, a 4 octet Original TTL		1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
	field, a 4 octet Signature Expiration field, a 4 octet Signature		TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
	Inception field, a 2 octet Key tag, the Signer's Name field, and the		Inception field, a 2 octet Key tag, the Signer's Name field, and the
	Signature field.		Signature field.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type Covered | Algorithm | Labels |		| Type Covered | Algorithm | Labels |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Original TTL |		| Original TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 13 ¶
	/ /		/ /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ /		/ /
	/ Signature /		/ Signature /
	/ /		/ /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.1.1 The Type Covered Field		3.1.1 The Type Covered Field
	The Type Covered field identifies the type of the RRset which is		The Type Covered field identifies the type of the RRset which is
	covered by this SIG record.		covered by this RRSIG record.
	If Type Covered field has a value of 0, the record is referred to as
	a transaction signature; please see [7] for further details.
	3.1.2 The Algorithm Number Field		3.1.2 The Algorithm Number Field
	The Algorithm Number field identifies the cryptographic algorithm		The Algorithm Number field identifies the cryptographic algorithm
	used to create the signature. A list of DNSSEC algorithm types can		used to create the signature. A list of DNSSEC algorithm types can
	be found in Appendix A.1		be found in Appendix A.1
	3.1.3 The Labels Field		3.1.3 The Labels Field
	The Labels field specifies the number of labels in the original SIG		The Labels field specifies the number of labels in the original RRSIG
	RR owner name. It is included to handle signatures associated with		RR owner name. The significance of this field is that from it a
	wildcard owner names.		verifier can determine if the answer was synthesized from a wildcard.
			If so, it can be used to determine what owner name was used in
			generating the signature.
	To validate a signature, the validator requires the original owner		To validate a signature, the validator needs the original owner name
	name that was used when the signature was created. If the original		that was used to create the signature. If the original owner name
	owner name contains a wildcard label ("*"), the owner name may have		contains a wildcard label ("*"), the owner name may have been
	been expanded by the server during the response process, in which		expanded by the server during the response process, in which case the
	case the validator will need to reconstruct the original owner name		validator will need to reconstruct the original owner name in order
	in order to validate the signature. [11] describes how to use the		to validate the signature. [I-D.ietf-dnsext-dnssec-protocol]
	Labels field to reconstruct the original owner name.		describes how to use the Labels field to reconstruct the original
			owner name.
	The value of the Label field MUST NOT count either the null (root)		The value of the Label field MUST NOT count either the null (root)
	label that terminates the owner name or the wildcard label (if		label that terminates the owner name or the wildcard label (if
	present). The value of the Label field MUST be less than or equal to		present). The value of the Label field MUST be less than or equal to
	the number of labels in the SIG owner name. For example,		the number of labels in the RRSIG owner name. For example,
	"www.example.com." has a Label field value of 3, and "*.example.com."		"www.example.com." has a Label field value of 3, and "*.example.com."
	has a Label field value of 2. Root (".") has a Label field value of		has a Label field value of 2. Root (".") has a Label field value of
	0.		0.
	Note that, although the wildcard label is not included in the count		Note that, although the wildcard label is not included in the count
	stored in the Label field of the SIG RR, the wildcard label is part		stored in the Label field of the RRSIG RR, the wildcard label is part
	of the RRset's owner name when generating or verifying the signature.		of the RRset's owner name when generating or verifying the signature.
	3.1.4 Original TTL Field		3.1.4 Original TTL Field
	The Original TTL field specifies the TTL of the covered RRset as it		The Original TTL field specifies the TTL of the covered RRset as it
	appears in the authoritative zone.		appears in the authoritative zone.
	The Original TTL field is necessary because a caching resolver		The Original TTL field is necessary because a caching resolver
	decrements the TTL value of a cached RRset. In order to validate a		decrements the TTL value of a cached RRset. In order to validate a
	signature, a resolver requires the original TTL. [11] describes how		signature, a resolver requires the original TTL.
	to use the Original TTL field value to reconstruct the original TTL.		[I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
			TTL field value to reconstruct the original TTL.
	The Original TTL value MUST be greater than or equal to the TTL value		The Original TTL value MUST be greater than or equal to the TTL value
	of the SIG record itself.		of the RRSIG record itself.
	3.1.5 Signature Expiration and Inception Fields		3.1.5 Signature Expiration and Inception Fields
	The Signature Expiration and Inception fields specify a validity		The Signature Expiration and Inception fields specify a validity
	period for the signature. The SIG record MUST NOT be used for		period for the signature. The RRSIG record MUST NOT be used for
	authentication prior to the inception date and MUST NOT be used for		authentication prior to the inception date and MUST NOT be used for
	authentication after the expiration date.		authentication after the expiration date.
	Signature Expiration and Inception field values are in POSIX.1 time		Signature Expiration and Inception field values are in POSIX.1 time
	format, a 32-bit unsigned number of seconds elapsed since 1 January		format: a 32-bit unsigned number of seconds elapsed since 1 January
	1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The		1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The
	longest interval which can be expressed by this format without		longest interval which can be expressed by this format without
	wrapping is approximately 136 years. A SIG RR can have an Expiration		wrapping is approximately 136 years. A RRSIG RR can have an
	field value which is numerically smaller than the Inception field		Expiration field value which is numerically smaller than the
	value if the expiration field value is near the 32-bit wrap-around		Inception field value if the expiration field value is near the
	point or if the signature is long lived. Because of this, all		32-bit wrap-around point or if the signature is long lived. Because
	comparisons involving these fields MUST use "Serial number		of this, all comparisons involving these fields MUST use "Serial
	arithmetic" as defined in [4]. As a direct consequence, the values		number arithmetic" as defined in [RFC1982]. As a direct consequence,
	contained in these fields cannot refer to dates more than 68 years in		the values contained in these fields cannot refer to dates more than
	either the past or the future.		68 years in either the past or the future.
	3.1.6 The Key Tag Field		3.1.6 The Key Tag Field
	The Key Tag field contains the key tag value of the KEY RR that		The Key Tag field contains the key tag value of the DNSKEY RR that
	validates this signature. The process of calculating the Key Tag		validates this signature. Appendix B explains how to calculate Key
	value is given in Appendix B.		Tag values.
	3.1.7 The Signer's Name Field		3.1.7 The Signer's Name Field
	The Signer's Name field value identifies the owner name of the KEY RR		The Signer's Name field value identifies the owner name of the DNSKEY
	used to authenticate this signature. The Signer's Name field MUST		RR which a security-aware resolver should use to validate this
	contain the name of the zone of the covered RRset, unless the Type		signature. The Signer's Name field MUST contain the name of the zone
	Covered field value is 0. A sender MUST NOT use DNS name compression		of the covered RRset. A sender MUST NOT use DNS name compression on
	on the Signer's Name field when transmitting a SIG RR. A receiver		the Signer's Name field when transmitting a RRSIG RR. A receiver
	which receives a SIG RR containing a compressed Signer's Name field		which receives a RRSIG RR containing a compressed Signer's Name field
	SHOULD decompress the field value.		SHOULD decompress the field value.
	3.1.8 The Signature Field		3.1.8 The Signature Field
	The Signature field contains the cryptographic signature which covers		The Signature field contains the cryptographic signature which covers
	the SIG RDATA (excluding the Signature field) and the RRset specified		the RRSIG RDATA (excluding the Signature field) and the RRset
	by the SIG owner name, SIG class, and SIG Type Covered field.		specified by the RRSIG owner name, RRSIG class, and RRSIG Type
			Covered field.
	3.1.8.1 Signature Calculation		3.1.8.1 Signature Calculation
	A signature covers the SIG RDATA (excluding the Signature Field) and		A signature covers the RRSIG RDATA (excluding the Signature Field)
	covers the RRset specified by the SIG owner name, SIG class, and SIG		and covers the data RRset specified by the RRSIG owner name, RRSIG
	Type Covered field. The RRset is in canonical form (see Section 6)		class, and RRSIG Type Covered field. The RRset is in canonical form
	and the set RR(1),...RR(n) is signed as follows:		(see Section 6) and the set RR(1),...RR(n) is signed as follows:
	signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where		signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
	"|" denotes concatenation;		"|" denotes concatenation;
	SIG_RDATA is the wire format of the SIG RDATA fields with		RRSIG_RDATA is the wire format of the RRSIG RDATA fields
	the Signer's Name field in canonical form and		with the Signer's Name field in canonical form and
	the Signature field excluded;		the Signature field excluded;
	RR(i) = owner | class | type | TTL | RDATA length | RDATA;		RR(i) = owner | class | type | TTL | RDATA length | RDATA;
	"owner" is the fully qualified owner name of the RRset in		"owner" is the fully qualified owner name of the RRset in
	canonical form (for RRs with wildcard owner names, the		canonical form (for RRs with wildcard owner names, the
	wildcard label is included in the owner name);		wildcard label is included in the owner name);
	Each RR MUST have the same owner name as the SIG RR;		Each RR MUST have the same owner name as the RRSIG RR;
	Each RR MUST have the same class as the SIG RR;		Each RR MUST have the same class as the RRSIG RR;
	Each RR in the RRset MUST have the RR type listed in the		Each RR in the RRset MUST have the RR type listed in the
	SIG RR's Type Covered field;		RRSIG RR's Type Covered field;
	Each RR in the RRset MUST have the TTL listed in the SIG		Each RR in the RRset MUST have the TTL listed in the
	Original TTL Field;		RRSIG Original TTL Field;
	Any DNS names in the RDATA field of each RR MUST be in		Any DNS names in the RDATA field of each RR MUST be in
	canonical form; and		canonical form; and
	The RRset MUST be sorted in canonical order.		The RRset MUST be sorted in canonical order.
	3.2 The SIG RR Presentation Format		3.2 The RRSIG RR Presentation Format
	The presentation format of the RDATA portion is as follows:		The presentation format of the RDATA portion is as follows:
	The Type Covered field value is represented either as an unsigned		The Type Covered field value MUST be represented either as an
	decimal integer or as the mnemonic for the covered RR type.		unsigned decimal integer or as the mnemonic for the covered RR type.
	The Algorithm field value is represented either as an unsigned		The Algorithm field value MUST be represented either as an unsigned
	decimal integer or as an algorithm mnemonic as specified in Appendix		decimal integer or as an algorithm mnemonic as specified in Appendix
	A.1.		A.1.
	The Labels field value is represented as an unsigned decimal integer.		The Labels field value MUST be represented as an unsigned decimal
	The Original TTL field value is represented as an unsigned decimal
	integer.		integer.
	The Signature Inception Time and Expiration Time field values are		The Original TTL field value MUST be represented as an unsigned
			decimal integer.
			The Signature Inception Time and Expiration Time field values MUST be
	represented in the form YYYYMMDDHHmmSS in UTC, where:		represented in the form YYYYMMDDHHmmSS in UTC, where:
	YYYY is the year (0000-9999, but see Section 3.1.5);		YYYY is the year (0000-9999, but see Section 3.1.5);
	MM is the month number (01-12);		MM is the month number (01-12);
	DD is the day of the month (01-31);		DD is the day of the month (01-31);
	HH is the hour in 24 hours notation (00-23);		HH is the hour in 24 hours notation (00-23);
	mm is the minute (00-59);		mm is the minute (00-59);
	SS is the second (00-59).		SS is the second (00-59).
	The Key Tag field is represented as an unsigned decimal integer.		The Key Tag field MUST be represented as an unsigned decimal integer.
	The Signer's Name field value is represented as a fully qualified		The Signer's Name field value MUST be represented as a domain name.
	domain name.
	The Signature field is represented as a Base64 encoding of the		The Signature field is represented as a Base64 encoding of the
	signature. Whitespace is allowed within the Base64 text. For a		signature. Whitespace is allowed within the Base64 text. For a
	definition of Base64 encoding see [3] Section 5.2.		definition of Base64 encoding see [RFC1521] Section 5.2.
	3.3 SIG RR Example		3.3 RRSIG RR Example
	The following a SIG RR stores the signature for the A RRset of		The following a RRSIG RR stores the signature for the A RRset of
	host.example.com:		host.example.com:
	host.example.com. 86400 IN SIG A 5 3 86400 20030322173103 (		host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
	20030220173103 2642 example.com.		20030220173103 2642 example.com.
	oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr		oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
	PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o		PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
	B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t		B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
	GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG		GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
	J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )		J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
	The first four fields specify the owner name, TTL, Class, and RR type		The first four fields specify the owner name, TTL, Class, and RR type
	(SIG). The "A" represents the Type Covered field. The value 5		(RRSIG). The "A" represents the Type Covered field. The value 5
	identifies the Algorithm used (RSA-SHA1) to create the signature.		identifies the Algorithm used (RSA-SHA1) to create the signature.
	The value 3 is the number of Labels in the original owner name. The		The value 3 is the number of Labels in the original owner name. The
	value 86400 in the SIG RDATA is the Original TTL for the covered A		value 86400 in the RRSIG RDATA is the Original TTL for the covered A
	RRset. 20030322173103 and 20030220173103 are the expiration and		RRset. 20030322173103 and 20030220173103 are the expiration and
	inception dates, respectively. 2642 is the Key Tag, and example.com.		inception dates, respectively. 2642 is the Key Tag, and example.com.
	is the Signer's Name. The remaining text is a Base64 encoding of the		is the Signer's Name. The remaining text is a Base64 encoding of the
	signature.		signature.
	Note that combination of SIG RR owner name, class, and Type Covered		Note that combination of RRSIG RR owner name, class, and Type Covered
	indicate that this SIG covers the "host.example.com" A RRset. The		indicate that this RRSIG covers the "host.example.com" A RRset. The
	Label value of 3 indicates that no wildcard expansion was used. The		Label value of 3 indicates that no wildcard expansion was used. The
	Algorithm, Signer's Name, and Key Tag indicate this signature can be		Algorithm, Signer's Name, and Key Tag indicate this signature can be
	authenticated using an example.com zone KEY RR whose algorithm is 5		authenticated using an example.com zone DNSKEY RR whose algorithm is
	and key tag is 2642.		5 and key tag is 2642.
	4. The NXT Resource Record		4. The NSEC Resource Record
	The NXT resource record lists two separate things: the owner name of		The NSEC resource record lists two separate things: the owner name of
	the next authoritative RRset in the canonical ordering of the zone,		the next authoritative RRset in the canonical ordering of the zone,
	and the set of RR types present at the NXT RR's owner name. The		and the set of RR types present at the NSEC RR's owner name. The
	complete set of NXT RRs in a zone both indicate which authoritative		complete set of NSEC RRs in a zone both indicate which authoritative
	RRsets exist in a zone and also form a chain of authoritative owner		RRsets exist in a zone and also form a chain of authoritative owner
	names in the zone. This information is used to provide authenticated		names in the zone. This information is used to provide authenticated
	denial of existence for DNS data, as described in [11].		denial of existence for DNS data, as described in
			[I-D.ietf-dnsext-dnssec-protocol].
	The type value for the NXT RR is 30.		The type value for the NSEC RR is 47.
	The NXT RR is class independent.		The NSEC RR is class independent.
	4.1 NXT RDATA Wire Format		The NSEC RR has no special TTL requirements.
	The RDATA of the NXT RR is as shown below:		4.1 NSEC RDATA Wire Format
			The RDATA of the NSEC RR is as shown below:
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Next Domain Name /		/ Next Domain Name /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Type Bit Map /		/ Type Bit Map /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	4.1.1 The Next Domain Name Field		4.1.1 The Next Domain Name Field
	The Next Domain Name field contains the owner name of the next		The Next Domain Name field contains the owner name of the next
	authoritative RRset in the canonical ordering of the zone; see		authoritative RRset in the canonical ordering of the zone; see
	Section 6.1 for an explanation of canonical ordering. The value of		Section 6.1 for an explanation of canonical ordering. The value of
	the Next Domain Name field in the last NXT record in the zone is the		the Next Domain Name field in the last NSEC record in the zone is the
	name of the zone apex (the owner name name of the zone's SOA RR).		name of the zone apex (the owner name name of the zone's SOA RR).
	A sender MUST NOT use DNS name compression on the Next Domain Name		A sender MUST NOT use DNS name compression on the Next Domain Name
	field when transmitting an NXT RR. A receiver which receives an NXT		field when transmitting an NSEC RR. A receiver which receives an
	RR containing a compressed Next Domain Name field SHOULD decompress		NSEC RR containing a compressed Next Domain Name field SHOULD
	the field value.		decompress the field value.
	Owner names of non-authoritative RRsets (such as glue records) MUST		Owner names of RRsets not authoritative for the given zone (such as
	NOT be listed in the Next Domain Name unless at least one		glue records) MUST NOT be listed in the Next Domain Name unless at
	authoritative RRset exists at the same owner name.		least one authoritative RRset exists at the same owner name.
	4.1.2 The Type Bit Map Field		4.1.2 The Type Bit Map Field
	The Type Bit Map field identifies the RRset types which exist at the		The Type Bit Map field identifies the RRset types which exist at the
	NXT RR's owner name.		NSEC RR's owner name.
	Each bit in the Type Bit Map field corresponds to an RR type. Bit 1		Each bit in the Type Bit Map field corresponds to an RR type. Bit 1
	corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS),		corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS),
	and so forth. If a bit is set to 1, it indicates that an RRset of		and so forth. If a bit is set to 1, it indicates that an RRset of
	that type is present for the NXT's owner name. If a bit is set to 0,		that type is present for the NSEC's owner name. If a bit is set to 0,
	it indicates that no RRset of that type present for the NXT's owner		it indicates that no RRset of that type present for the NSEC's owner
	name.		name.
	Bit 1 MUST NOT indicate glue address records.		A zone MUST NOT generate an NSEC RR for any domain name that only
			holds glue records.
	Bit 41 MUST have the value of 0, since the OPT pseudo-RR [6] can		Bits representing pseudo-RR types MUST be set to 0, since they do not
	never appear in zone data.		appear in zone data. If encountered, they must be ignored upon
			reading.
	Trailing zero octets MUST be omitted. The length of the Type Bit Map		Trailing zero octets MUST be omitted. The length of the Type Bit Map
	field varies, and is determined by the type code with the largest		field varies, and is determined by the type code with the largest
	numerical value among the set of RR types present at the NXT RR's		numerical value among the set of RR types present at the NSEC RR's
	owner name. Trailing zero octets not specified MUST be interpreted		owner name. Trailing zero octets not specified MUST be interpreted
	as zero octets.		as zero octets.
	The above Type Bit Map format MUST NOT be used when an RR type code		The above Type Bit Map format MUST NOT be used when an RR type code
	with numerical value greater than 127 is present.		with numerical value greater than 127 is present.
	Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A		Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A
	value of 0 in bit 0 denotes the format described above, therefore bit		value of 0 in bit 0 denotes the format described above, therefore bit
	0 MUST have a value of 0. The format and meaning of a Type Bit Map		0 MUST have a value of 0. The format and meaning of a Type Bit Map
	with a value of 1 in bit 0 is undefined.		with a value of 1 in bit 0 is undefined.
	4.1.3 Inclusion of Wildcard Names in NXT RDATA		4.1.3 Inclusion of Wildcard Names in NSEC RDATA
	If a wildcard owner name appears in a zone, the wildcard label ("*")		If a wildcard owner name appears in a zone, the wildcard label ("*")
	is treated as a literal symbol and is treated the same as any other		is treated as a literal symbol and is treated the same as any other
	owner name for purposes of generating NXT RRs. Wildcard owner names		owner name for purposes of generating NSEC RRs. Wildcard owner names
	appear in the Next Domain Name field without any wildcard expansion.		appear in the Next Domain Name field without any wildcard expansion.
	[11] describes the impact of wildcards on authenticated denial of		[I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards
	existence.		on authenticated denial of existence.
	4.2 The NXT RR Presentation Format		4.2 The NSEC RR Presentation Format
	The presentation format of the RDATA portion is as follows:		The presentation format of the RDATA portion is as follows:
	The Next Domain Name field is represented as a domain name.		The Next Domain Name field is represented as a domain name.
	The Type Bit Map field is represented either as a sequence of RR type		The Type Bit Map field is represented either as a sequence of RR type
	mnemonics or as a sequence of unsigned decimal integers denoting the		mnemonics or as a sequence of unsigned decimal integers denoting the
	RR type codes.		RR type codes.
	4.3 NXT RR Example		4.3 NSEC RR Example
	The following NXT RR identifies the RRsets associated with		The following NSEC RR identifies the RRsets associated with
	alfa.example.com. and identifies the next authoritative name after		alfa.example.com. and identifies the next authoritative name after
	alfa.example.com.		alfa.example.com.
	alfa.example.com. 86400 IN NXT host.example.com. A MX SIG NXT		alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC
	The first four text fields specify the name, TTL, Class, and RR type		The first four text fields specify the name, TTL, Class, and RR type
	(NXT). The entry host.example.com. is the next authoritative name		(NSEC). The entry host.example.com. is the next authoritative name
	after alfa.example.com. (in canonical order). The A, MX, SIG and		after alfa.example.com. in canonical order. The A, MX, RRSIG and NSEC
	NXT mnemonics indicate there are A, MX, SIG and NXT RRsets associated		mnemonics indicate there are A, MX, RRSIG and NSEC RRsets associated
	with the name alfa.example.com.		with the name alfa.example.com.
	Note the NXT record can be used for authenticated denial of		Note that the NSEC record can be used in authenticated denial of
	existence. If the example NXT record were authenticated, it could be		existence proofs. If the example NSEC record were authenticated, it
	used to prove that beta.example.com. does not exist, or could be		could be used to prove that beta.example.com does not exist or could
	used to prove there is no AAAA record associated with		be used to prove there is no AAAA record associated with
	alfa.example.com. Authenticated denial of existence is discussed in		alfa.example.com. Authenticated denial of existence is discussed in
	[11]		[I-D.ietf-dnsext-dnssec-protocol].
	5. The DS Resource Record		5. The DS Resource Record
	The DS Resource Record refers to a KEY RR and is used in the DNS KEY		The DS Resource Record refers to a DNSKEY RR and is used in the DNS
	authentication process. A DS RR refers to a KEY RR by storing the		DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
	key tag, algorithm number, and a digest of KEY RR. Note that while		storing the key tag, algorithm number, and a digest of the DNSKEY RR.
	the digest should be sufficient to identify the key, storing the key		Note that while the digest should be sufficient to identify the key,
	tag and key algorithm helps make the identification process more		storing the key tag and key algorithm helps make the identification
	efficient. By authenticating the DS record, a resolver can		process more efficient. By authenticating the DS record, a resolver
	authenticate the KEY RR to which the DS record points. The key		can authenticate the DNSKEY RR to which the DS record points. The
	authentication process is described in [11].		key authentication process is described in
			[I-D.ietf-dnsext-dnssec-protocol].
	The DS RR and its corresponding KEY RR have the same owner name, but		The DS RR and its corresponding DNSKEY RR have the same owner name,
	they are stored in different locations. The DS RR appears only on		but they are stored in different locations. The DS RR appears only
	the upper (parental) side of a delegation, and is authoritative data		on the upper (parental) side of a delegation, and is authoritative
	in the parent zone. For example, the DS RR for "example.com" is		data in the parent zone. For example, the DS RR for "example.com" is
	stored in the "com" zone (the parent zone) rather than in the		stored in the "com" zone (the parent zone) rather than in the
	"example.com" zone (the child zone). The corresponding KEY RR is		"example.com" zone (the child zone). The corresponding DNSKEY RR is
	stored in the "example.com" zone (the child zone). This simplifies		stored in the "example.com" zone (the child zone). This simplifies
	DNS zone management and zone signing, but introduces special response		DNS zone management and zone signing, but introduces special response
	processing requirements for the DS RR; these are described in [11].		processing requirements for the DS RR; these are described in
			[I-D.ietf-dnsext-dnssec-protocol].
	The type number for the DS record is 43.		The type number for the DS record is 43.
	The DS resource record is class independent.		The DS resource record is class independent.
	There are no special TTL requirements on the DS resource record.		The DS RR has no special TTL requirements.
	5.1 DS RDATA Wire Format		5.1 DS RDATA Wire Format
	The RDATA for a DS RR consists of 2 octet Key Tag field, a one octet		The RDATA for a DS RR consists of a 2 octet Key Tag field, a one
	Algorithm field, a one octet Digest Type field, and a Digest field.		octet Algorithm field, a one octet Digest Type field, and a Digest
			field.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Key Tag | Algorithm | Digest Type |		| Key Tag | Algorithm | Digest Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ /		/ /
	/ Digest /		/ Digest /
	/ /		/ /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5.1.1 The Key Tag Field		5.1.1 The Key Tag Field
	The Key Tag field lists the key tag of the KEY RR referred to by the		The Key Tag field lists the key tag of the DNSKEY RR referred to by
	DS record. The KEY RR MUST be a zone key. The KEY RR Flags MUST		the DS record.
	have Flags bit 7 set to value 1.
	The Key Tag used by the DS RR is identical to the Key Tag used by the		The Key Tag used by the DS RR is identical to the Key Tag used by
	SIG RR and Appendix B describes how to compute a Key Tag.		RRSIG RRs. Appendix B describes how to compute a Key Tag.
	5.1.2 The Algorithm Field		5.1.2 The Algorithm Field
	The Algorithm field lists the algorithm number of the KEY RR referred		The Algorithm field lists the algorithm number of the DNSKEY RR
	to by the DS record.		referred to by the DS record.
	The algorithm number used by the DS RR is identical to the algorithm		The algorithm number used by the DS RR is identical to the algorithm
	number used by the SIG RR and KEY RR. Appendix A.1 lists the		number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm
	algorithm number types.		number types.
	5.1.3 The Digest Type Field		5.1.3 The Digest Type Field
	The DS RR refers to a KEY RR by including a digest of that KEY RR.		The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
	The Digest Type field identifies the algorithm used to construct the		RR. The Digest Type field identifies the algorithm used to construct
	digest and Appendix A.2 lists the possible digest algorithm types.		the digest. Appendix A.2 lists the possible digest algorithm types.
	5.1.4 The Digest Field		5.1.4 The Digest Field
	The DS record refers to a KEY RR by including a digest of that KEY		The DS record refers to a DNSKEY RR by including a digest of that
	RR. The Digest field holds the digest.		DNSKEY RR. The Digest field holds the digest.
	The digest is calculated by concatenating the canonical form of the		The digest is calculated by concatenating the canonical form of the
	fully qualified owner name of the KEY RR (abbreviated below as "key		fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
	RR name") with the KEY RDATA, and then applying the digest algorithm.		and then applying the digest algorithm.
	digest = digest_algorithm( KEY RR name | KEY RDATA);		digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
	"|" denotes concatenation		"|" denotes concatenation
	KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key.		DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
	The size of the digest may vary depending on the digest algorithm and		The size of the digest may vary depending on the digest algorithm and
	KEY RR size. Currently, the defined digest algorithm is SHA-1, which		DNSKEY RR size. Currently, the only defined digest algorithm is
	produces a 20 octet digest.		SHA-1, which produces a 20 octet digest.
	5.2 The DS RR Presentation Format		5.2 Processing of DS RRs When Validating Responses
			The DS RR links the authentication chain across zone boundaries, so
			the DS RR requires extra care in processing. The DNSKEY RR referred
			to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST
			have Flags bit 7 set to value 1. If the key tag does not indicate a
			DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT be
			used in the validation process.
			5.3 The DS RR Presentation Format
	The presentation format of the RDATA portion is as follows:		The presentation format of the RDATA portion is as follows:
	The Key Tag field is represented as an unsigned decimal integer.		The Key Tag field MUST be represented as an unsigned decimal integer.
	The Algorithm field is represented either as an unsigned decimal		The Algorithm field MUST be represented either as an unsigned decimal
	integer or as an algorithm mnemonic specified in Appendix A.1.		integer or as an algorithm mnemonic specified in Appendix A.1.
	The Digest Type field is represented as an unsigned decimal integer.		The Digest Type field MUST be represented as an unsigned decimal
			integer.
	The Digest is represented as a sequence of case-insensitive		The Digest MUST be represented as a sequence of case-insensitive
	hexadecimal digits. Whitespace is allowed within the hexadecimal		hexadecimal digits. Whitespace is allowed within the hexadecimal
	text.		text.
	5.3 DS RR Example		5.4 DS RR Example
	The following example shows a KEY RR and its corresponding DS RR.		The following example shows a DNSKEY RR and its corresponding DS RR.
	dskey.example.com. 86400 IN KEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz		dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
	fwJr1AYtsmx3TGkJaNXVbfi/		fwJr1AYtsmx3TGkJaNXVbfi/
	2pHm822aJ5iI9BMzNXxeYCmZ		2pHm822aJ5iI9BMzNXxeYCmZ
	DRD99WYwYqUSdjMmmAphXdvx		DRD99WYwYqUSdjMmmAphXdvx
	egXd/M5+X7OrzKBaMbCVdFLU		egXd/M5+X7OrzKBaMbCVdFLU
	Uh6DhweJBjEVv5f2wwjM9Xzc		Uh6DhweJBjEVv5f2wwjM9Xzc
	nOf+EPbtG9DMBmADjFDc2w/r		nOf+EPbtG9DMBmADjFDc2w/r
	ljwvFw==		ljwvFw==
	) ; key id = 60485		) ; key id = 60485
	dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A		dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
	98631FAD1A292118 )		98631FAD1A292118 )
	The first four text fields specify the name, TTL, Class, and RR type		The first four text fields specify the name, TTL, Class, and RR type
	(DS). Value 60485 is the key tag for the corresponding		(DS). Value 60485 is the key tag for the corresponding
	"dskey.example.com." KEY RR, and value 5 denotes the algorithm used		"dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
	by this "dskey.example.com." KEY RR. The value 1 is the algorithm		used by this "dskey.example.com." DNSKEY RR. The value 1 is the
	used to construct the digest, and the rest of the RDATA text is the		algorithm used to construct the digest, and the rest of the RDATA
	digest in hexadecimal.		text is the digest in hexadecimal.
	6. Canonical Form and Order of Resource Records		6. Canonical Form and Order of Resource Records
	This section defines a canonical form for resource records, a		This section defines a canonical form for resource records, a
	canonical ordering of DNS names, and a canonical ordering of resource		canonical ordering of DNS names, and a canonical ordering of resource
	records within an RRset. A canonical name order is required to		records within an RRset. A canonical name order is required to
	construct the NXT name chain. A canonical RR form and ordering		construct the NSEC name chain. A canonical RR form and ordering
	within an RRset are required to construct and verify SIG RRs.		within an RRset are required to construct and verify RRSIG RRs.
	6.1 Canonical DNS Name Order		6.1 Canonical DNS Name Order
	For purposes of DNS security, owner names are ordered by treating		For purposes of DNS security, owner names are ordered by treating
	individual labels as unsigned left-justified octet strings. The		individual labels as unsigned left-justified octet strings. The
	absence of a octet sorts before a zero value octet, and upper case		absence of a octet sorts before a zero value octet, and upper case
	US-ASCII letters are treated as if they were lower case US-ASCII		US-ASCII letters are treated as if they were lower case US-ASCII
	letters.		letters.
	To compute the canonical ordering of a set of DNS names, start by		To compute the canonical ordering of a set of DNS names, start by
	skipping to change at page 22, line 9 ¶		skipping to change at page 22, line 9 ¶
	1. Every domain name in the RR is fully expanded (no DNS name		1. Every domain name in the RR is fully expanded (no DNS name
	compression) and fully qualified;		compression) and fully qualified;
	2. All uppercase US-ASCII letters in the owner name of the RR are		2. All uppercase US-ASCII letters in the owner name of the RR are
	replaced by the corresponding lowercase US-ASCII letters;		replaced by the corresponding lowercase US-ASCII letters;
	3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,		3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
	HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,		HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
	SRV, DNAME, or A6, all uppercase US-ASCII letters in the DNS		SRV, DNAME, or A6, all uppercase US-ASCII letters in the DNS
	names within the RDATA of the RR are replaced by the		names contained within the RDATA are replaced by the
	corresponding lowercase US-ASCII letters;		corresponding lowercase US-ASCII letters;
	4. If the owner name of the RR is a wildcard name, the owner name is		4. If the owner name of the RR is a wildcard name, the owner name is
	in its original unexpanded form, including the "*" label (no		in its original unexpanded form, including the "*" label (no
	wildcard substitution); and		wildcard substitution); and
	5. The RR's TTL is set to its original value as it appears in the		5. The RR's TTL is set to its original value as it appears in the
	authoritative zone containing the RR or the Original TTL field of		originating authoritative zone or the Original TTL field of the
	the covering SIG RR.		covering RRSIG RR.
	Editors' Note: the above definition sacrifices readability for an
	attempt at precision. Please send better text!
	6.3 Canonical RR Ordering Within An RRset		6.3 Canonical RR Ordering Within An RRset
	For purposes of DNS security, RRs with same owner name, same class,		For purposes of DNS security, RRs with same owner name, same class,
	and same type are sorted by sorting the canonical forms of the RRs		and same type are sorted by RDATA: first by RDATA length, shortest to
	while treating the RDATA portion of the canonical form of each RR as		longest, then by the canonical form of the RDATA itself in the case
	a left justified unsigned octet sequence. The absence of an octet		of length equality, treating the RDATA portion of the canonical form
	sorts before the zero octet.		of each RR as a left justified unsigned octet sequence. The absence
			of an octet sorts before a zero octet.
	7. IANA Considerations		7. IANA Considerations
	This document introduces one new IANA consideration. RFC 2535 [14]		This document introduces no new IANA considerations, because all of
	created an IANA registry for DNS Security Algorithm Numbers. This		the protocol parameters used in this document have already been
	document re-assigns DNS Security Algorithm Number 252 to be		assigned by previous specifications. However, since the evolution of
	"reserved". This value is no longer available for assignment by		DNSSEC has been long and somewhat convoluted, this section attempts
	IANA.		to describe the current state of the IANA registries and other
			protocol parameters which are (or once were) related to DNSSEC.
	This document clarifies the use of existing DNS resource records.		DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
	For completeness, the IANA considerations from the previous documents		the SIG, KEY, and NXT RRs, respectively.
	which defined these resource records are summarized below. No IANA		[I-D.ietf-dnsext-delegation-signer] assigned DNS Resource Record
	changes are made by this document other than the one change described		Type 43 to DS. [I-D.ietf-dnsext-dnssec-2535typecode-change]
	in the first paragraph of this section.		assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,
			respectively. [I-D.ietf-dnsext-dnssec-2535typecode-change] also
			marked type 30 (NXT) as Obsolete, and restricted use of types 24
			(SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol
			described in [RFC2931].
	[14] updated the IANA registry for DNS Resource Record Types, and		SIG(0) Algorithm Numbers: [RFC2535] created an IANA registry for
	assigned types 24,25, and 30 to the SIG, KEY, and NXT RRs,		DNSSEC Resource Record Algorithm field numbers, and assigned
	respectively. [9] assigned DNS Resource Record Type 43 to DS.		values 1-4 and 252-255. [RFC3110] assigned value 5.
			[I-D.ietf-dnsext-dnssec-2535typecode-change] renamed this registry
			to "SIG(0) Algorithm Numbers" to indicate that this registry is
			now used only by the "SIG(0)" transaction security protocol
			described in [RFC2931].
	[14] created an IANA registry for DNSSEC Resource Record Algorithm		DNS Security Algorithm Numbers:
	Numbers. Values to 1-4, and 252-255 were assigned by [14]. Value 5		[I-D.ietf-dnsext-dnssec-2535typecode-change] created a new "DNS
	was assigned by [8]. Value 252 is re-assigned by this document, as		Security Algorithm Numbers" registry, assigned initial values to
	noted above.		algorithms 2 (Diffie-Hellman), 3 (DSA/SHA-1), 5 (RSA/SHA-1), 253
			(private algorithms - domain name) and 254 (private algorithms -
			OID), and reserved values 0, 1, and 255. As stated in
			[I-D.ietf-dnsext-dnssec-2535typecode-change], value 4 and values
			6-252 are available for assignment by IETF Standards Action.
	[9] created an IANA registry for DNSSEC DS Digest Types, and assigned		[I-D.ietf-dnsext-delegation-signer] created an IANA registry for
	value 0 to reserved and value 1 to SHA-1.		DNSSEC DS Digest Types, and assigned value 0 to reserved and value
			1 to SHA-1.
	[14] created an IANA Registry for KEY Protocol Values, but [16] re-		KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
	assigned all assigned values other than 3 to reserved and closed this		Protocol Values, but [RFC3445] re-assigned all assigned values
	IANA registry. The registry remains closed, and all KEY records are		other than 3 to reserved and closed this IANA registry. The
	required to have Protocol Octet value of 3.		registry remains closed, and all KEY and DNSKEY records are
			required to have Protocol Octet value of 3.
	The Flag bits in the KEY RR are not assigned by IANA, and there is no		Flag bits in the KEY and DNSKEY RRs: The Flag bits in the KEY and
	IANA registry for these flags. All changes to the meaning of the KEY		DNSKEY RRs are not assigned by IANA, and there is no IANA registry
	RR Flag bits require a standards action.		for these flags. All changes to the meaning of the Flag bits in
			the KEY and DNSKEY RRs require a standards action.
	The meaning of a value of 1 in bit zero of the Type Bit Map of an NXT		Bit zero of Type Bit Map in NSEC RRs: The meaning of a value of 1 in
	RR can only be assigned by a standards action.		bit zero of the Type Bit Map of an NSEC RR can only be assigned by
			a standards action.
	8. Security Considerations		8. Security Considerations
	This document describes the format of four DNS resource records used		This document describes the format of four DNS resource records used
	by the DNS security extensions, and presents an algorithm for		by the DNS security extensions, and presents an algorithm for
	calculating a key tag for a public key. Other than the items		calculating a key tag for a public key. Other than the items
	described below, the resource records themselves introduce no		described below, the resource records themselves introduce no
	security considerations. The use of these records is specified in a		security considerations. The use of these records is specified in a
	separate document, and security considerations related to the use		separate document, and security considerations related to the use
	these resource records are discussed in that document.		these resource records are discussed in that document.
	The DS record points to a KEY RR using a cryptographic digest, the		The DS record points to a DNSKEY RR using a cryptographic digest, the
	key algorithm type and a key tag. The DS record is intended to		key algorithm type and a key tag. The DS record is intended to
	identify an existing KEY RR, but it is theoretically possible for an		identify an existing DNSKEY RR, but it is theoretically possible for
	attacker to generate a KEY that matches all the DS fields. The		an attacker to generate a DNSKEY that matches all the DS fields. The
	probability of constructing such a matching KEY depends on the type		probability of constructing such a matching DNSKEY depends on the
	of digest algorithm in use. The only currently defined digest		type of digest algorithm in use. The only currently defined digest
	algorithm is SHA-1, and the working group believes that constructing		algorithm is SHA-1, and the working group believes that constructing
	a public key which would match the algorithm, key tag, and SHA-1		a public key which would match the algorithm, key tag, and SHA-1
	digest given in a DS record would be a sufficiently difficult problem		digest given in a DS record would be a sufficiently difficult problem
	that such an attack is not a serious threat at this time.		that such an attack is not a serious threat at this time.
	The key tag is used to help select KEY resource records efficiently,		The key tag is used to help select DNSKEY resource records
	but it does not uniquely identify a single KEY resource record. It		efficiently, but it does not uniquely identify a single DNSKEY
	is possible for two distinct KEY RRs to have the same owner name, the		resource record. It is possible for two distinct DNSKEY RRs to have
	same algorithm type, and the same key tag. An implementation which		the same owner name, the same algorithm type, and the same key tag.
	used only the key tag to select a KEY RR might select the wrong		An implementation which used only the key tag to select a DNSKEY RR
	public key in some circumstances. Implementations MUST NOT assume		might select the wrong public key in some circumstances.
	the key tag is unique public key identifier; this is clearly stated
	in Appendix B.
	9. Acknowledgments		9. Acknowledgments
	This document was created from the input and ideas of several members		This document was created from the input and ideas of several members
	of the DNS Extensions Working Group and working group mailing list.		of the DNS Extensions Working Group and working group mailing list.
	The co-authors of this draft would like to express their thanks for		The co-authors of this draft would like to express their thanks for
	the comments and suggestions received during the revision of these		the comments and suggestions received during the revision of these
	security extension specifications.		security extension specifications.
	Normative References		Normative References
	[1] Mockapetris, P., "Domain names - concepts and facilities", STD		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[2] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail		[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
	Extensions) Part One: Mechanisms for Specifying and Describing		Mail Extensions) Part One: Mechanisms for Specifying and
	the Format of Internet Message Bodies", RFC 1521, September		Describing the Format of Internet Message Bodies", RFC
	1993.		1521, September 1993.
	[4] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
	August 1996.		August 1996.
	[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,		[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
	August 1999.		Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
			April 1997.
	[7] Eastlake, D., "DNS Request and Transaction Signatures (		[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	SIG(0)s)", RFC 2931, September 2000.		Specification", RFC 2181, July 1997.
	[8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name		[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
	System (DNS)", RFC 3110, May 2001.		NCACHE)", RFC 2308, March 1998.
	[9] Gudmundsson, O., "Delegation Signer Resource Record", draft-		[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
	ietf-dnsext-delegation-signer-12 (work in progress), December		2671, August 1999.
	2002.
	[10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,		[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
	"DNS Security Introduction and Requirements", draft-ietf-		SIG(0)s)", RFC 2931, September 2000.
	dnsext-dnssec-intro-05 (work in progress), February 2003.
	[11] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,		[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
	"Protocol Modifications for the DNS Security Extensions",		Name System (DNS)", RFC 3110, May 2001.
	draft-ietf-dnsext-dnssec-protocol-00 (work in progress),
	Februari 2003.
	[12] Gustafsson, A., "Handling of Unknown DNS RR Types", draft-ietf-		[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
	dnsext-unknown-rrs-04 (work in progress), September 2002.		Resource Record (RR)", RFC 3445, December 2002.
	[13] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft-		[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
	ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003.		(RR) Types", RFC 3597, September 2003.
	Informative References		[I-D.ietf-dnsext-delegation-signer]
			Gudmundsson, O., "Delegation Signer Resource Record",
			draft-ietf-dnsext-delegation-signer-15 (work in progress),
			June 2003.
	[14] Eastlake, D., "Domain Name System Security Extensions", RFC		[I-D.ietf-dnsext-dnssec-intro]
	2535, March 1999.		Arends, R., Austein, R., Larson, M., Massey, D. and S.
			Rose, "DNS Security Introduction and Requirements",
			draft-ietf-dnsext-dnssec-intro-06 (work in progress),
			September 2003.
	[15] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC		[I-D.ietf-dnsext-dnssec-protocol]
	2930, September 2000.		Arends, R., Austein, R., Larson, M., Massey, D. and S.
			Rose, "Protocol Modifications for the DNS Security
			Extensions", draft-ietf-dnsext-dnssec-protocol-02 (work in
			progress), September 2003.
	[16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource		[I-D.ietf-dnsext-keyrr-key-signing-flag]
	Record (RR)", RFC 3445, December 2002.		Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
			Entry Point (SEP) Flag",
			draft-ietf-dnsext-keyrr-key-signing-flag-08 (work in
			progress), July 2003.
			[I-D.ietf-dnsext-dnssec-2535typecode-change]
			Weiler, S., "Legacy Resolver Compatibility for Delegation
			Signer", draft-ietf-dnsext-dnssec-2535typecode-change-04
			(work in progress), August 2003.
			Informative References
			[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
			RFC 2535, March 1999.
			[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
			RR)", RFC 2930, September 2000.
	Authors' Addresses		Authors' Addresses
	Roy Arends		Roy Arends
	Telematica Instituut		Telematica Instituut
	Drienerlolaan 5		Drienerlolaan 5
	7522 NB Enschede		7522 NB Enschede
	NL		NL
	EMail: roy.arends@telin.nl		EMail: roy.arends@telin.nl
	skipping to change at page 29, line 8 ¶		skipping to change at page 31, line 8 ¶
	National Institute for Standards and Technology		National Institute for Standards and Technology
	100 Bureau Drive		100 Bureau Drive
	Gaithersburg, MD 20899-8920		Gaithersburg, MD 20899-8920
	USA		USA
	EMail: scott.rose@nist.gov		EMail: scott.rose@nist.gov
	Appendix A. DNSSEC Algorithm and Digest Types		Appendix A. DNSSEC Algorithm and Digest Types
	The DNS security extensions are designed to be independent of the		The DNS security extensions are designed to be independent of the
	underlying cryptographic algorithms. The KEY, SIG, and DS resource		underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS
	records all use a DNSSEC Algorithm Number to identify the		resource records all use a DNSSEC Algorithm Number to identify the
	cryptographic algorithm in use by the resource record. The DS		cryptographic algorithm in use by the resource record. The DS
	resource record also specifies a Digest Algorithm Number to identify		resource record also specifies a Digest Algorithm Number to identify
	the digest algorithm used to construct the DS record. The currently		the digest algorithm used to construct the DS record. The currently
	defined Algorithm and Digest Types are listed below. Additional		defined Algorithm and Digest Types are listed below. Additional
	Algorithm or Digest Types could be added as advances in cryptography		Algorithm or Digest Types could be added as advances in cryptography
	warrant.		warrant.
	A DNSSEC aware resolver or name server MUST implement all MANDATORY		A DNSSEC aware resolver or name server MUST implement all MANDATORY
	algorithms.		algorithms.
	A.1 DNSSEC Algorithm Types		A.1 DNSSEC Algorithm Types
	An "Algorithm Number" field in the KEY, SIG, and DS resource record		An "Algorithm Number" field in the DNSKEY, RRSIG, and DS resource
	types identifies the cryptographic algorithm used by the resource		record types identifies the cryptographic algorithm used by the
	record. Algorithm specific formats are described in separate		resource record. Algorithm specific formats are described in
	documents. The following table lists the currently defined algorithm		separate documents. The following table lists the currently defined
	types and provides references to their supporting documents:		algorithm types and provides references to their supporting
			documents:
	VALUE Algorithm RFC STATUS		VALUE Algorithm [mnemonic] RFC STATUS
	0 Reserved - -		0 Reserved - -
	1 RSA/MD5 RFC 2537 NOT RECOMMENDED		1 RSA/MD5 [RSA/MD5] RFC 2537 NOT RECOMMENDED
	2 Diffie-Hellman RFC 2539 OPTIONAL		2 Diffie-Hellman [DH] RFC 2539 OPTIONAL
	3 DSA RFC 2536 OPTIONAL		3 DSA [DSA] RFC 2536 OPTIONAL
	4 elliptic curve TBA OPTIONAL		4 elliptic curve [ECC] TBA OPTIONAL
	5 RSA/SHA1 RFC 3110 MANDATORY		5 RSA/SHA1 [RSA/SHA1] RFC 3110 MANDATORY
	6-251 available for assignment -		6-251 available for assignment -
	252 reserved -		252 reserved -
	253 private see below OPTIONAL		253 private [PRIVATE_DNS] see below OPTIONAL
	254 private see below OPTIONAL		254 private [PRIVATE_OID] see below OPTIONAL
	255 reserved - -		255 reserved - -
	A.1.1 Private Algorithm Types		A.1.1 Private Algorithm Types
	Algorithm number 253 is reserved for private use and will never be		Algorithm number 253 is reserved for private use and will never be
	assigned to a specific algorithm. The public key area in the KEY RR		assigned to a specific algorithm. The public key area in the DNSKEY
	and the signature area in the SIG RR begin with a wire encoded domain		RR and the signature area in the RRSIG RR begin with a wire encoded
	name. Only local domain name compression is permitted. The domain		domain name, which MUST NOT be compressed. The domain name indicates
	name indicates the private algorithm to use and the remainder of the		the private algorithm to use and the remainder of the public key area
	public key area is determined by that algorithm. Entities should		is determined by that algorithm. Entities should only use domain
	only use domain names they control to designate their private		names they control to designate their private algorithms.
	algorithms.
	Algorithm number 254 is reserved for private use and will never be		Algorithm number 254 is reserved for private use and will never be
	assigned to a specific algorithm. The public key area in the KEY RR		assigned to a specific algorithm. The public key area in the DNSKEY
	and the signature area in the SIG RR begin with an unsigned length		RR and the signature area in the RRSIG RR begin with an unsigned
	byte followed by a BER encoded Object Identifier (ISO OID) of that		length byte followed by a BER encoded Object Identifier (ISO OID) of
	length. The OID indicates the private algorithm in use and the		that length. The OID indicates the private algorithm in use and the
	remainder of the area is whatever is required by that algorithm.		remainder of the area is whatever is required by that algorithm.
	Entities should only use OIDs they control to designate their private		Entities should only use OIDs they control to designate their private
	algorithms.		algorithms.
	A.2 DNSSEC Digest Types		A.2 DNSSEC Digest Types
	A "Digest Type" field in the DS resource record types identifies the		A "Digest Type" field in the DS resource record types identifies the
	cryptographic digest algorithm used by the resource record. The		cryptographic digest algorithm used by the resource record. The
	following table lists the currently defined digest algorithm types.		following table lists the currently defined digest algorithm types.
	VALUE Algorithm STATUS		VALUE Algorithm STATUS
	0 Reserved -		0 Reserved -
	1 SHA-1 MANDATORY		1 SHA-1 MANDATORY
	2-255 Unassigned -		2-255 Unassigned -
	Appendix B. Key Tag Calculation		Appendix B. Key Tag Calculation
	The Key Tag field in the SIG and DS resource record types provides a		The Key Tag field in the RRSIG and DS resource record types provides
	mechanism for selecting a public key efficiently. In most cases, a		a mechanism for selecting a public key efficiently. In most cases, a
	combination of owner name, algorithm, and key tag can efficiently		combination of owner name, algorithm, and key tag can efficiently
	identify a KEY record. Both the SIG and DS resource records have		identify a DNSKEY record. Both the RRSIG and DS resource records
	corresponding KEY records. The Key Tag field in the SIG and DS		have corresponding DNSKEY records. The Key Tag field in the RRSIG
	records can be used to help select the corresponding KEY RR		and DS records can be used to help select the corresponding DNSKEY RR
	efficiently when more than one candidate KEY RR is available.		efficiently when more than one candidate DNSKEY RR is available.
	However, it is essential to note that the key tag is not a unique		However, it is essential to note that the key tag is not a unique
	identifier. It is theoretically possible for two distinct KEY RRs to		identifier. It is theoretically possible for two distinct DNSKEY RRs
	have the same owner name, the same algorithm, and the same key tag.		to have the same owner name, the same algorithm, and the same key
	The key tag is used to limit the possible candidate keys, but it does		tag. The key tag is used to limit the possible candidate keys, but it
	not uniquely identify a KEY record. Implementations MUST NOT assume		does not uniquely identify a DNSKEY record. Implementations MUST NOT
	that the key tag uniquely identifies a KEY RR.		assume that the key tag uniquely identifies a DNSKEY RR.
	The key tag is the same for all KEY algorithm types except algorithm		The key tag is the same for all DNSKEY algorithm types except
	1 (please see Appendix B.1 for the definition of the key tag for		algorithm 1 (please see Appendix B.1 for the definition of the key
	algorithm 1). For all algorithms other than algorithm 1, the key tag		tag for algorithm 1). The key tag algorithm is the sum of the wire
	is defined to be the output which would be generated by running the		format of the DNSKEY RDATA broken into 2 octet groups. First the
	ANSI C function shown below with the RDATA portion of the KEY RR as		RDATA (in wire format) is treated as a series of 2 octet groups,
	input. It is not necessary to use the following reference code		these groups are then added together ignoring any carry bits. A
	verbatim, but the numerical value of the Key Tag MUST be identical to		reference implementation of the key tag algorithm is as am ANSI C
	what the reference implementation would generate for the same input.		function is given below with the RDATA portion of the DNSKEY RR is
			used as input. It is not necessary to use the following reference
			code verbatim, but the numerical value of the Key Tag MUST be
			identical to what the reference implementation would generate for the
			same input.
	Please note that the algorithm for calculating the Key Tag is almost		Please note that the algorithm for calculating the Key Tag is almost
	but not completely identical to the familiar ones complement checksum		but not completely identical to the familiar ones complement checksum
	used in many other Internet protocols. Key Tags MUST be calculated		used in many other Internet protocols. Key Tags MUST be calculated
	using the algorithm described below rather than the ones complement		using the algorithm described here rather than the ones complement
	checksum.		checksum.
	The following ANSI C reference implementation calculates the value of		The following ANSI C reference implementation calculates the value of
	a Key Tag. This reference implementation applies to all algorithm		a Key Tag. This reference implementation applies to all algorithm
	types except algorithm 1 (see Appendix B.1). The input is the wire		types except algorithm 1 (see Appendix B.1). The input is the wire
	format of the RDATA portion of the KEY RR. The code is written for		format of the RDATA portion of the DNSKEY RR. The code is written
	clarity, not efficiency.		for clarity, not efficiency.
	/*		/*
	* Assumes that int is at least 16 bits.		* Assumes that int is at least 16 bits.
	* First octet of the key tag is the most significant 8 bits of the		* First octet of the key tag is the most significant 8 bits of the
	* return value;		* return value;
	* Second octet of the key tag is the least significant 8 bits of the		* Second octet of the key tag is the least significant 8 bits of the
	* return value.		* return value.
	*/		*/
	unsigned int		unsigned int
	keytag (		keytag (
	unsigned char key[], /* the RDATA part of the KEY RR */		unsigned char key[], /* the RDATA part of the DNSKEY RR */
	unsigned int keysize /* the RDLENGTH */		unsigned int keysize /* the RDLENGTH */
	)		)
	{		{
	unsigned long ac; /* assumed to be 32 bits or larger */		unsigned long ac; /* assumed to be 32 bits or larger */
	int i; /* loop index */		int i; /* loop index */
	for ( ac = 0, i = 0; i < keysize; ++i )		for ( ac = 0, i = 0; i < keysize; ++i )
	ac += (i & 1) ? key[i] : key[i] << 8;		ac += (i & 1) ? key[i] : key[i] << 8;
	ac += (ac >> 16) & 0xFFFF;		ac += (ac >> 16) & 0xFFFF;
	return ac & 0xFFFF;		return ac & 0xFFFF;
	}		}
	B.1 Key Tag for Algorithm 1 (RSA/MD5)		B.1 Key Tag for Algorithm 1 (RSA/MD5)
	The key tag for algorithm 1 (RSA/MD5) is defined differently than the		The key tag for algorithm 1 (RSA/MD5) is defined differently than the
	key tag for all other algorithms, for historical reasons. For a KEY		key tag for all other algorithms, for historical reasons. For a
	RR with algorithm 1, the key tag is defined to be the most		DNSKEY RR with algorithm 1, the key tag is defined to be the most
	significant 16 bits of the least significant 24 bits in the public		significant 16 bits of the least significant 24 bits in the public
	key modulus (in other words, the 4th to last and 3rd to last octets		key modulus (in other words, the 4th to last and 3rd to last octets
	of the public key modulus).		of the public key modulus).
	Please note that Algorithm 1 is NOT RECOMMENDED.		Please note that Algorithm 1 is NOT RECOMMENDED.
			Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			intellectual property or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication and any assurances of
			licenses to be made available, or the result of an attempt made to
			obtain a general license or permission for the use of such
			proprietary rights by implementors or users of this specification can
			be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). 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
	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 assignees.
	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
End of changes. 200 change blocks.
	449 lines changed or deleted		539 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/