< draft-ietf-dnsext-dnssec-records-04.txt		draft-ietf-dnsext-dnssec-records-05.txt >
	DNS Extensions R. Arends		DNS Extensions R. Arends
	Internet-Draft Telematica Instituut		Internet-Draft Telematica Instituut
	Expires: March 16, 2004 R. Austein		Expires: April 26, 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
	September 16, 2003		October 27, 2003
	Resource Records for the DNS Security Extensions		Resource Records for the DNS Security Extensions
	draft-ietf-dnsext-dnssec-records-04		draft-ietf-dnsext-dnssec-records-05
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 March 16, 2004.		This Internet-Draft will expire on April 26, 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
	public key (DNSKEY), delegation signer (DS), resource record digital		public key (DNSKEY), delegation signer (DS), resource record digital
	signature (RRSIG), and authenticated denial of existance (NSEC)		signature (RRSIG), and authenticated denial of existence (NSEC)
	resource records. The purpose and format of each resource record is		resource records. The purpose and format of each resource record is
	described in detail, and an example of each resource record is given.		described in detail, and an example of each resource record is given.
	This document obsoletes RFC 2535 and incorporates changes from all		This document obsoletes RFC 2535 and incorporates changes from all
	updates to RFC 2535.		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
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9		3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9
	3.1 RRSIG 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 RRSIG RR Presentation Format . . . . . . . . . . . . . . 13		3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 12
	3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13		3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13
	4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15		4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15
	4.1 NSEC 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 . . . . . . . . . . . . . . . . . . . 16		4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 16
	4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 16		4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 16
	4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 16		4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 16
	4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17		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
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	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: DNSKEY, RRSIG, NSEC, 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 [RFC1034], RFC1035 [RFC1035] and subsequent		described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs
	RFC's that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and		that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308
	RFC2308 [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 and data integrity the Domain Name System		add source authentication and data integrity to the Domain Name
	(DNS). An introduction to DNSSEC and definition of common terms can		System (DNS). An introduction to DNSSEC and definition of common
	be found in [I-D.ietf-dnsext-dnssec-intro]. A description of DNS		terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description
	protocol modifications can be found in		of DNS protocol modifications can be found in
	[I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC		[I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC
	resource records.		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 [RFC2119].		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 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
	out the RFC that defines the correct behavior. For a technical		out the RFC that defines the correct behavior. For a technical
	change where no RFC that defines the correct behavior, or if there's		change where no RFC that defines the correct behavior, or if there's
	more than one applicable RFC and the definitions conflict, please		more than one applicable RFC and the definitions conflict, please
	post the issue to namedroppers.		post the issue to namedroppers.
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	2. The DNSKEY 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 DNSKEY		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 [I-D.ietf-dnsext-dnssec-protocol]. For example, a zone		described in [I-D.ietf-dnsext-dnssec-protocol]. For example, a zone
	signs its authoritative RRsets using a private key and stores the		signs its authoritative RRsets using a private key and stores the
	corresponding public key in a DNSKEY RR. A resolver can then use		corresponding public key in a DNSKEY RR. A resolver can then use
	these signatures to authenticate RRsets from the zone.		these signatures to authenticate RRsets from the zone.
	The DNSKEY RR may also be used to store public keys associated with		The DNSKEY RR is not intended as a record for storing arbitrary
	other DNS operations such as TKEY [RFC2930]. The DNSKEY RR is not,		public keys, and MUST NOT be used to store certificates or public
	however, intended as a record for storing arbitrary public keys. The		keys that do not directly relate to the DNS infrastructure.
	DNSKEY RR MUST NOT be used to store certificates or public keys that
	do not directly relate to the DNS infrastructure.
	The Type value for the DNSKEY RR type is 48.		The Type value for the DNSKEY RR type is 48.
	The DNSKEY RR is class independent.		The DNSKEY RR is class independent.
	The DNSKEY RR has no special TTL requirements.		The DNSKEY RR has no special TTL requirements.
	2.1 DNSKEY RDATA Wire Format		2.1 DNSKEY RDATA Wire Format
	The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1		The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
	octet Protocol Field, a 1 octet Algorithm Field , and the Public Key		octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
	Field.		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 DNSKEY record holds a DNS zone key and the DNSKEY's owner		then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner
	name MUST be the name of a zone. If bit 7 has value 0, then the		name MUST be the name of a zone. If bit 7 has value 0, then the
	DNSKEY record holds some other type of DNS public key, such as a		DNSKEY record holds some other type of DNS public key, such as a
	public key used by TKEY.		public key used by TKEY.
	Bit 15 of the Flags field is the Secure Entry Point flag, described		Bit 15 of the Flags field is the Secure Entry Point flag, described
	in [I-D.ietf-dnsext-keyrr-key-signing-flag]. If bit 15 has value 1,		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		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		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;		debugging software as to the intended use of this DNSKEY record;
	security-aware resolvers MUST NOT alter their behavior during the		security-aware resolvers MUST NOT alter their behavior during the
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 16 ¶
	DNSSEC uses public key cryptography to sign and authenticate DNS		DNSSEC uses public key cryptography to sign and authenticate DNS
	resource record sets (RRsets). Digital signatures are stored in		resource record sets (RRsets). Digital signatures are stored in
	RRSIG resource records and are used in the DNSSEC authentication		RRSIG resource records and are used in the DNSSEC authentication
	process described in [I-D.ietf-dnsext-dnssec-protocol]. A		process described in [I-D.ietf-dnsext-dnssec-protocol]. A
	security-aware resolver can use these RRSIG RRs to authenticate		security-aware resolver can use these RRSIG RRs to authenticate
	RRsets from the zone. The RRSIG RR MUST only be used to carry		RRsets from the zone. The RRSIG RR MUST only be used to carry
	verification material (digital signatures) used to secure DNS		verification material (digital signatures) used to secure DNS
	operations.		operations.
	A RRSIG record contains the signature for an RRset with a particular		An RRSIG record contains the signature for an RRset with a particular
	name, class, and type. The RRSIG RR specifies a validity interval		name, class, and type. The RRSIG RR specifies a validity interval
	for the signature and uses the Algorithm, the Signer's Name, and the		for the signature and uses the Algorithm, the Signer's Name, and the
	Key Tag to identify the DNSKEY RR containing the public key that a		Key Tag to identify the DNSKEY RR containing the public key that a
	resolver can use to verify the signature.		resolver can use to verify the signature.
	The Type value for the RRSIG RR type is 46.		The Type value for the RRSIG RR type is 46.
	The RRSIG RR is class independent.		The RRSIG RR is class independent.
	A RRSIG RR MUST have the same class as the RRset it covers.		An RRSIG RR MUST have the same class as the RRset it covers.
	The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset		The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
	it covers.		it covers.
	3.1 RRSIG RDATA Wire Format		3.1 RRSIG RDATA Wire Format
	The RDATA for a RRSIG RR consists of a 2 octet Type Covered field, a		The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
	1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original		1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
	TTL 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 11, line 16 ¶		skipping to change at page 11, line 16 ¶
	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.		signature, a resolver requires the original TTL.
	[I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original		[I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
	TTL field value to reconstruct the original TTL.		TTL field value to reconstruct the original TTL.
	The Original TTL value MUST be greater than or equal to the TTL value
	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 RRSIG 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 RRSIG RR can have an		wrapping is approximately 136 years. An RRSIG RR can have an
	Expiration field value which is numerically smaller than the		Expiration field value which is numerically smaller than the
	Inception field value if the expiration field value is near the		Inception field value if the expiration field value is near the
	32-bit wrap-around point or if the signature is long lived. Because		32-bit wrap-around point or if the signature is long lived. Because
	of this, all comparisons involving these fields MUST use "Serial		of this, all comparisons involving these fields MUST use "Serial
	number arithmetic" as defined in [RFC1982]. As a direct consequence,		number arithmetic" as defined in [RFC1982]. As a direct consequence,
	the values contained in these fields cannot refer to dates more than		the values contained in these fields cannot refer to dates more than
	68 years in 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
	skipping to change at page 11, line 52 ¶		skipping to change at page 11, line 49 ¶
	validates this signature. Appendix B explains how to calculate Key		validates this signature. Appendix B explains how to calculate Key
	Tag values.		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 DNSKEY		The Signer's Name field value identifies the owner name of the DNSKEY
	RR which a security-aware resolver should use to validate this		RR which a security-aware resolver should use to validate this
	signature. The Signer's Name field MUST contain the name of the zone		signature. The Signer's Name field MUST contain the name of the zone
	of the covered RRset. A sender MUST NOT use DNS name compression on		of the covered RRset. A sender MUST NOT use DNS name compression on
	the Signer's Name field when transmitting a RRSIG RR. A receiver		the Signer's Name field when transmitting a RRSIG RR. A receiver
	which receives a RRSIG RR containing a compressed Signer's Name field		which receives an RRSIG RR containing a compressed Signer's Name
	SHOULD decompress the field value.		field 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 RRSIG RDATA (excluding the Signature field) and the RRset		the RRSIG RDATA (excluding the Signature field) and the RRset
	specified by the RRSIG owner name, RRSIG class, and RRSIG Type		specified by the RRSIG owner name, RRSIG class, and RRSIG Type
	Covered field.		Covered field.
	3.1.8.1 Signature Calculation		3.1.8.1 Signature Calculation
	skipping to change at page 13, line 47 ¶		skipping to change at page 13, line 43 ¶
	The Key Tag field MUST be represented as an unsigned decimal integer.		The Key Tag field MUST be represented as an unsigned decimal integer.
	The Signer's Name field value MUST be represented as a domain name.		The Signer's Name field value MUST be represented as a 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 [RFC1521] Section 5.2.		definition of Base64 encoding see [RFC1521] Section 5.2.
	3.3 RRSIG RR Example		3.3 RRSIG RR Example
	The following a RRSIG RR stores the signature for the A RRset of		The following an RRSIG RR stores the signature for the A RRset of
	host.example.com:		host.example.com:
	host.example.com. 86400 IN RRSIG 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= )
	skipping to change at page 15, line 40 ¶		skipping to change at page 15, line 40 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ 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 NSEC 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 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 NSEC RR. A receiver which receives an		field when transmitting an NSEC RR. A receiver which receives an
	NSEC RR containing a compressed Next Domain Name field SHOULD		NSEC RR containing a compressed Next Domain Name field SHOULD
	decompress the field value.		decompress the field value.
	Owner names of RRsets not authoritative for the given zone (such as		Owner names of RRsets not authoritative for the given zone (such as
	glue records) MUST NOT be listed in the Next Domain Name unless at		glue records) MUST NOT be listed in the Next Domain Name unless at
	least one 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
	NSEC 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 NSEC's owner name. If a bit is set to 0,		that type is present for the NSEC RR's owner name. If a bit is set to
	it indicates that no RRset of that type present for the NSEC's owner		0, it indicates that no RRset of that type present for the NSEC RR's
	name.		owner name.
	A zone MUST NOT generate an NSEC RR for any domain name that only		A zone MUST NOT generate an NSEC RR for any domain name that only
	holds glue records.		holds glue records.
	Bits representing pseudo-RR types MUST be set to 0, since they do not		Bits representing pseudo-RR types MUST be set to 0, since they do not
	appear in zone data. If encountered, they must be ignored upon		appear in zone data. If encountered, they must be ignored upon
	reading.		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
	skipping to change at page 17, line 23 ¶		skipping to change at page 17, line 23 ¶
	alfa.example.com.		alfa.example.com.
	alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC		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
	(NSEC). 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, RRSIG and NSEC		after alfa.example.com. in canonical order. The A, MX, RRSIG and NSEC
	mnemonics indicate there are A, MX, RRSIG and NSEC 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 that the NSEC record can be used in authenticated denial of		Assuming that the resolver can authenticate this NSEC record, it
	existence proofs. If the example NSEC record were authenticated, it		could be used to prove that beta.example.com does not exist, or could
	could be used to prove that beta.example.com does not exist or could
	be 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
	[I-D.ietf-dnsext-dnssec-protocol].		[I-D.ietf-dnsext-dnssec-protocol].
	5. The DS Resource Record		5. The DS Resource Record
	The DS Resource Record refers to a DNSKEY RR and is used in the DNS		The DS Resource Record refers to a DNSKEY RR and is used in the DNS
	DNSKEY authentication process. A DS RR refers to a DNSKEY RR by		DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
	storing the key tag, algorithm number, and a digest of the DNSKEY RR.		storing the key tag, algorithm number, and a digest of the DNSKEY RR.
	Note that while the digest should be sufficient to identify the key,		Note that while the digest should be sufficient to identify the key,
	skipping to change at page 22, line 8 ¶		skipping to change at page 22, line 8 ¶
	format of the RR where:		format of the RR where:
	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, A6, RRSIG or NSEC, all uppercase US-ASCII letters in
	names contained within the RDATA are replaced by the		the DNS 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
	originating authoritative zone or the Original TTL field of the		originating authoritative zone or the Original TTL field of the
	covering RRSIG RR.		covering RRSIG RR.
	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 the same owner name, class,
	and same type are sorted by RDATA: first by RDATA length, shortest to		and type are sorted by RDATA: first by RDATA length, shortest to
	longest, then by the canonical form of the RDATA itself in the case		longest, then by the canonical form of the RDATA itself in the case
	of length equality, treating the RDATA portion of the canonical form		of length equality, treating the RDATA portion of the canonical form
	of each RR as a left justified unsigned octet sequence. The absence		of each RR as a left justified unsigned octet sequence. The absence
	of an octet sorts before a zero octet.		of an octet sorts before a zero octet.
	7. IANA Considerations		7. IANA Considerations
	This document introduces no new IANA considerations, because all of		This document introduces no new IANA considerations, because all of
	the protocol parameters used in this document have already been		the protocol parameters used in this document have already been
	assigned by previous specifications. However, since the evolution of		assigned by previous specifications. However, since the evolution of
	skipping to change at page 26, line 9 ¶		skipping to change at page 26, line 9 ¶
	efficiently, but it does not uniquely identify a single DNSKEY		efficiently, but it does not uniquely identify a single DNSKEY
	resource record. It is possible for two distinct DNSKEY RRs to have		resource record. It is possible for two distinct DNSKEY RRs to have
	the same owner name, the same algorithm type, and the same key tag.		the same owner name, the same algorithm type, and the same key tag.
	An implementation which used only the key tag to select a DNSKEY RR		An implementation which used only the key tag to select a DNSKEY RR
	might select the wrong public key in some circumstances.		might select the wrong public key in some circumstances.
	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 editors would like to express their thanks for the comments and
	the comments and suggestions received during the revision of these		suggestions received during the revision of these security extension
	security extension specifications.		specifications.
	Normative References		Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[RFC1035] 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.
	[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet		[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
	skipping to change at page 28, line 8 ¶		skipping to change at page 28, line 8 ¶
	(RR) Types", RFC 3597, September 2003.		(RR) Types", RFC 3597, September 2003.
	[I-D.ietf-dnsext-delegation-signer]		[I-D.ietf-dnsext-delegation-signer]
	Gudmundsson, O., "Delegation Signer Resource Record",		Gudmundsson, O., "Delegation Signer Resource Record",
	draft-ietf-dnsext-delegation-signer-15 (work in progress),		draft-ietf-dnsext-delegation-signer-15 (work in progress),
	June 2003.		June 2003.
	[I-D.ietf-dnsext-dnssec-intro]		[I-D.ietf-dnsext-dnssec-intro]
	Arends, R., Austein, R., Larson, M., Massey, D. and S.		Arends, R., Austein, R., Larson, M., Massey, D. and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	draft-ietf-dnsext-dnssec-intro-06 (work in progress),		draft-ietf-dnsext-dnssec-intro-07 (work in progress),
	September 2003.		October 2003.
	[I-D.ietf-dnsext-dnssec-protocol]		[I-D.ietf-dnsext-dnssec-protocol]
	Arends, R., Austein, R., Larson, M., Massey, D. and S.		Arends, R., Austein, R., Larson, M., Massey, D. and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", draft-ietf-dnsext-dnssec-protocol-02 (work in		Extensions", draft-ietf-dnsext-dnssec-protocol-03 (work in
	progress), September 2003.		progress), October 2003.
	[I-D.ietf-dnsext-keyrr-key-signing-flag]		[I-D.ietf-dnsext-keyrr-key-signing-flag]
	Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure		Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
	Entry Point (SEP) Flag",		Entry Point Flag",
	draft-ietf-dnsext-keyrr-key-signing-flag-08 (work in		draft-ietf-dnsext-keyrr-key-signing-flag-11 (work in
	progress), July 2003.		progress), October 2003.
	[I-D.ietf-dnsext-dnssec-2535typecode-change]		[I-D.ietf-dnsext-dnssec-2535typecode-change]
	Weiler, S., "Legacy Resolver Compatibility for Delegation		Weiler, S., "Legacy Resolver Compatibility for Delegation
	Signer", draft-ietf-dnsext-dnssec-2535typecode-change-04		Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05
	(work in progress), August 2003.		(work in progress), October 2003.
	Informative References		Informative References
	[RFC2535] Eastlake, D., "Domain Name System Security Extensions",		[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
	RFC 2535, March 1999.		RFC 2535, March 1999.
	[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY		[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
	RR)", RFC 2930, September 2000.		RR)", RFC 2930, September 2000.
	Authors' Addresses		Authors' Addresses
	skipping to change at page 33, line 28 ¶		skipping to change at page 33, line 28 ¶
	tag. The key tag is used to limit the possible candidate keys, but it		tag. The key tag is used to limit the possible candidate keys, but it
	does not uniquely identify a DNSKEY record. Implementations MUST NOT		does not uniquely identify a DNSKEY record. Implementations MUST NOT
	assume that the key tag uniquely identifies a DNSKEY RR.		assume that the key tag uniquely identifies a DNSKEY RR.
	The key tag is the same for all DNSKEY algorithm types except		The key tag is the same for all DNSKEY algorithm types except
	algorithm 1 (please see Appendix B.1 for the definition of the key		algorithm 1 (please see Appendix B.1 for the definition of the key
	tag for algorithm 1). The key tag algorithm is the sum of the wire		tag for algorithm 1). The key tag algorithm is the sum of the wire
	format of the DNSKEY RDATA broken into 2 octet groups. First the		format of the DNSKEY RDATA broken into 2 octet groups. First the
	RDATA (in wire format) is treated as a series of 2 octet groups,		RDATA (in wire format) is treated as a series of 2 octet groups,
	these groups are then added together ignoring any carry bits. A		these groups are then added together ignoring any carry bits. A
	reference implementation of the key tag algorithm is as am ANSI C		reference implementation of the key tag algorithm is as an ANSI C
	function is given below with the RDATA portion of the DNSKEY RR is		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		used as input. It is not necessary to use the following reference
	code verbatim, but the numerical value of the Key Tag MUST be		code verbatim, but the numerical value of the Key Tag MUST be
	identical to what the reference implementation would generate for the		identical to what the reference implementation would generate for the
	same input.		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 here rather than the ones complement		using the algorithm described here rather than the ones complement
End of changes. 30 change blocks.
	55 lines changed or deleted		49 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/