< draft-ietf-dnsext-dnssec-records-06.txt		draft-ietf-dnsext-dnssec-records-07.txt >
	DNS Extensions R. Arends		DNS Extensions R. Arends
	Internet-Draft Telematica Instituut		Internet-Draft Telematica Instituut
	Expires: June 16, 2004 R. Austein		Expires: August 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
	December 17, 2003		February 16, 2004
	Resource Records for the DNS Security Extensions		Resource Records for the DNS Security Extensions
	draft-ietf-dnsext-dnssec-records-06		draft-ietf-dnsext-dnssec-records-07
	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 June 16, 2004.		This Internet-Draft will expire on August 16, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). 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 existence (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
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 10 ¶
	A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33		A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33
	B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34		B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34
	B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35		B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35
	Intellectual Property and Copyright Statements . . . . . . . 36		Intellectual Property and Copyright Statements . . . . . . . 36
	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.		presentation format (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 RFCs		described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs
	that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308		that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and 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 to the Domain Name		add source authentication and data integrity to the Domain Name
	System (DNS). An introduction to DNSSEC and definition of common		System (DNS). An introduction to DNSSEC and definitions of common
	terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description		terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description
	of DNS 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].
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	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 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]: A zone signs its
	signs its authoritative RRsets using a private key and stores the		authoritative RRsets using a private key and stores the corresponding
	corresponding public key in a DNSKEY RR. A resolver can then use		public key in a DNSKEY RR. A resolver can then use the public key to
	these signatures to authenticate RRsets from the zone.		authenticate signatures covering the RRsets in the zone.
	The DNSKEY RR is not intended as a record for storing arbitrary		The DNSKEY RR is not intended as a record for storing arbitrary
	public keys, and MUST NOT be used to store certificates or public		public keys, and MUST NOT be used to store certificates or public
	keys that do not directly relate to the DNS infrastructure.		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.
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 47 ¶
	/ 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 RR'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 and MUST NOT be used to verify RRSIGs that
			cover RRsets.
	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
	signature validation process in any way based on the setting of this		signature validation process in any way based on the setting of this
	bit.		bit.
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 27 ¶
	during signature verification if found to be some value other than 3.		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 itself.		The Public Key Field holds the public key material. The format
			depends on the algorithm of the key being stored and are described in
			separate documents.
	2.1.5 Notes on DNSKEY 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 early versions of the KEY record.		backward compatibility with early versions of the KEY record.
	2.2 The DNSKEY 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:
	skipping to change at page 9, line 38 ¶		skipping to change at page 9, line 38 ¶
	zone.		zone.
	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.
	An 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. This is an exception to the [RFC2181] rules for TTL		it covers. This is an exception to the [RFC2181] rules for TTL
	values of individuals RRs within a RRset: individual RRSIG with the		values of individual RRs within a RRset: individual RRSIG with the
	same owner name will have different TTLs if the RRsets that they		same owner name will have different TTL values if the RRsets that
	cover have different TTLs.		they cover have different TTL values.
	3.1 RRSIG RDATA Wire Format		3.1 RRSIG RDATA Wire Format
	The RDATA for an 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
	skipping to change at page 10, line 49 ¶		skipping to change at page 10, line 49 ¶
	To validate a signature, the validator needs the original owner name		To validate a signature, the validator needs the original owner name
	that was used to create the signature. If the original owner name		that was used to create the signature. If the original owner name
	contains a wildcard label ("*"), the owner name may have been		contains a wildcard label ("*"), the owner name may have been
	expanded by the server during the response process, in which case the		expanded by the server during the response process, in which case the
	validator will need to reconstruct the original owner name in order		validator will need to reconstruct the original owner name in order
	to validate the signature. [I-D.ietf-dnsext-dnssec-protocol]		to validate the signature. [I-D.ietf-dnsext-dnssec-protocol]
	describes how to use the Labels field to reconstruct the original		describes how to use the Labels field to reconstruct the original
	owner name.		owner name.
	The value of the Label field MUST NOT count either the null (root)		The value of the Labels 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 Labels field MUST be less than or equal
	the number of labels in the RRSIG owner name. For example,		to 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 Labels field value of 3, and
	has a Label field value of 2. Root (".") has a Label field value of		"*.example.com." has a Labels field value of 2. Root (".") has a
	0.		Labels field value of 0.
	Note that, although the wildcard label is not included in the count		Although the wildcard label is not included in the count stored in
	stored in the Label field of the RRSIG RR, the wildcard label is part		the Labels field of the RRSIG RR, the wildcard label is part of the
	of the RRset's owner name when generating or verifying the signature.		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.		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
	skipping to change at page 12, line 20 ¶		skipping to change at page 12, line 20 ¶
	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 an RRSIG RR containing a compressed Signer's Name		which receives an RRSIG RR containing a compressed Signer's Name
	field 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. The format of this field depends on the algorithm in
			use and these formats are described in separate companion documents.
	3.1.8.1 Signature Calculation		3.1.8.1 Signature Calculation
	A signature covers the RRSIG RDATA (excluding the Signature Field)		A signature covers the RRSIG RDATA (excluding the Signature Field)
	and covers the data RRset specified by the RRSIG owner name, RRSIG		and covers the data RRset specified by the RRSIG owner name, RRSIG
	class, and RRSIG Type Covered field. The RRset is in canonical form		class, and RRSIG Type Covered fields. The RRset is in canonical form
	(see Section 6) 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(RRSIG_RDATA | RR(1) | RR(2)... ) where		signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
	"|" denotes concatenation;		"|" denotes concatenation;
	RRSIG_RDATA is the wire format of the RRSIG RDATA fields		RRSIG_RDATA is the wire format of the RRSIG RDATA fields
	with 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;
	skipping to change at page 13, line 26 ¶		skipping to change at page 13, line 26 ¶
	The Algorithm field value MUST be 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 MUST be represented as an unsigned decimal		The Labels field value MUST be represented as an unsigned decimal
	integer.		integer.
	The Original TTL field value MUST be represented as an unsigned		The Original TTL field value MUST be represented as an unsigned
	decimal integer.		decimal integer.
	The Signature Inception Time and Expiration Time field values MUST be		The Signature Expiration Time and Inception 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);
	skipping to change at page 14, line 17 ¶		skipping to change at page 14, line 17 ¶
	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= )
	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
	(RRSIG). 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 RRSIG 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 RRSIG RR owner name, class, and Type Covered		Note that combination of RRSIG RR owner name, class, and Type Covered
	indicate that this RRSIG 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
	skipping to change at page 15, line 27 ¶		skipping to change at page 15, line 27 ¶
	chain, NSEC RRs must be present for names containing a CNAME RR.		chain, NSEC RRs must be present for names containing a CNAME RR.
	This is a change to the traditional DNS specification [RFC1034] that		This is a change to the traditional DNS specification [RFC1034] that
	stated that if a CNAME is present for a name, it is the only type		stated that if a CNAME is present for a name, it is the only type
	allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist		allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist
	for the same name as a CNAME resource record in a secure zone.		for the same name as a CNAME resource record in a secure zone.
	The type value for the NSEC RR is 47.		The type value for the NSEC RR is 47.
	The NSEC RR is class independent.		The NSEC RR is class independent.
	The NSEC RR has no special TTL requirements.		The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
			field. This is in the spirt of negative caching [RFC2308].
	4.1 NSEC RDATA Wire Format		4.1 NSEC RDATA Wire Format
	The RDATA of the NSEC RR is as shown below:		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 Maps /		/ Type Bit Maps /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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 owner name 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 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
	skipping to change at page 17, line 38 ¶		skipping to change at page 17, line 39 ¶
	The following NSEC 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 NSEC host.example.com. (		alfa.example.com. 86400 IN NSEC host.example.com. (
	A MX RRSIG NSEC TYPE1234 )		A MX RRSIG NSEC TYPE1234 )
	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, NSEC,
	mnemonics indicate there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets		and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
	associated with the name alfa.example.com.		TYPE1234 RRsets associated with the name alfa.example.com.
	The RDATA section of the NSEC RR above would be encoded as:		The RDATA section of the NSEC RR above would be encoded as:
	0x04 'h' 'o' 's' 't'		0x04 'h' 'o' 's' 't'
	0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'		0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
	0x03 'c' 'o' 'm' 0x00		0x03 'c' 'o' 'm' 0x00
	0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03		0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
	0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00		0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
	0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00		0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00		0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	skipping to change at page 20, line 31 ¶		skipping to change at page 20, line 31 ¶
	5.1.3 The Digest Type Field		5.1.3 The Digest Type Field
	The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY		The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
	RR. The Digest Type field identifies the algorithm used to construct		RR. The Digest Type field identifies the algorithm used to construct
	the digest. 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 DNSKEY RR by including a digest of that		The DS record refers to a DNSKEY RR by including a digest of that
	DNSKEY RR. The Digest field holds the digest.		DNSKEY RR.
	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 DNSKEY RR with the DNSKEY RDATA,		fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
	and then applying the digest algorithm.		and then applying the digest algorithm.
	digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);		digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
	"|" denotes concatenation		"|" denotes concatenation
	DNSKEY 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
	DNSKEY RR size. Currently, the only defined digest algorithm is		DNSKEY RR size. As of the time of writing, the only defined digest
	SHA-1, which produces a 20 octet digest.		algorithm is SHA-1, which produces a 20 octet digest.
	5.2 Processing of DS RRs When Validating Responses		5.2 Processing of DS RRs When Validating Responses
	The DS RR links the authentication chain across zone boundaries, so		The DS RR links the authentication chain across zone boundaries, so
	the DS RR requires extra care in processing. The DNSKEY RR referred		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		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		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		DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT be
	used in the validation process.		used in the validation process.
	skipping to change at page 23, line 23 ¶		skipping to change at page 23, line 23 ¶
	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 the same owner name, class,		For purposes of DNS security, RRs with the same owner name, class,
	and type are sorted by RDATA: first by RDATA length, shortest to		and type are sorted by treating the RDATA portion of the canonical
	longest, then by the canonical form of the RDATA itself in the case		form of each RR as a left-justified unsigned octet sequence where the
	of length equality, treating the RDATA portion of the canonical form		absence of an octet sorts before a zero octet.
	of each RR as a left justified unsigned octet sequence. The absence
	of an octet sorts before a zero octet.
	[RFC2181] specifies that an RRset is not allowed to contain duplicate		[RFC2181] specifies that an RRset is not allowed to contain duplicate
	records (multiple RRs with the same owner name, class, type, and		records (multiple RRs with the same owner name, class, type, and
	RDATA). Therefore, if an implementation detects duplicate RRs during		RDATA). Therefore, if an implementation detects duplicate RRs during
	RRset canonicalization, the implementation MUST treat this as a		RRset canonicalization, the implementation MUST treat this as a
	protocol error. If the implementation chooses to handle this		protocol error. If the implementation chooses to handle this
	protocol error in the spirit of the robustness principle (being		protocol error in the spirit of the robustness principle (being
	liberal in what it accepts), the implementation MUST remove all but		liberal in what it accepts), the implementation MUST remove all but
	one of the duplicate RR(s) for purposes of calculating the canonical		one of the duplicate RR(s) for purposes of calculating the canonical
	form of the RRset.		form of the RRset.
	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
	DNSSEC has been long and somewhat convoluted, this section attempts		DNSSEC has been long and somewhat convoluted, this section attempts
	to describe the current state of the IANA registries and other		to describe the current state of the IANA registries and other
	protocol parameters which are (or once were) related to DNSSEC.		protocol parameters which are (or once were) related to DNSSEC.
			Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA
			considerations.
	DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to		DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
	the SIG, KEY, and NXT RRs, respectively.		the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS
	[I-D.ietf-dnsext-delegation-signer] assigned DNS Resource Record		Resource Record Type 43 to DS.
	Type 43 to DS. [I-D.ietf-dnsext-dnssec-2535typecode-change]		[I-D.ietf-dnsext-dnssec-2535typecode-change] assigned types 46,
	assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,		47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
	respectively. [I-D.ietf-dnsext-dnssec-2535typecode-change] also		[I-D.ietf-dnsext-dnssec-2535typecode-change] also marked type 30
	marked type 30 (NXT) as Obsolete, and restricted use of types 24		(NXT) as Obsolete, and restricted use of types 24 (SIG) and 25
	(SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol		(KEY) to the "SIG(0)" transaction security protocol described in
	described in [RFC2931].		[RFC2931] and the transaction KEY Resource Record described in
			[RFC2930].
	DNS Security Algorithm Numbers: [RFC2535] created an IANA registry		DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
	for DNSSEC Resource Record Algorithm field numbers, and assigned		for DNSSEC Resource Record Algorithm field numbers, and assigned
	values 1-4 and 252-255. [RFC3110] assigned value 5.		values 1-4 and 252-255. [RFC3110] assigned value 5.
	[I-D.ietf-dnsext-dnssec-2535typecode-change] altered this registry		[I-D.ietf-dnsext-dnssec-2535typecode-change] altered this registry
	to include flags for each entry regarding its use with the DNS		to include flags for each entry regarding its use with the DNS
	security extensions. Each algorithm entry could refer to an		security extensions. Each algorithm entry could refer to an
	algorithm that can be used for zone signing, transaction security		algorithm that can be used for zone signing, transaction security
	(see [RFC2931]) or both. Values 6-251 are available for assignment		(see [RFC2931]) or both. Values 6-251 are available for assignment
	by IETF standards action. See Appendix A for a full listing of the		by IETF standards action. See Appendix A for a full listing of the
	DNS Security Algorithm Numbers entries at the time of writing and		DNS Security Algorithm Numbers entries at the time of writing and
	their status of use in DNSSEC.		their status of use in DNSSEC.
	[I-D.ietf-dnsext-delegation-signer] created an IANA registry for		[RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
	DNSSEC DS Digest Types, and assigned value 0 to reserved and value		assigned value 0 to reserved and value 1 to SHA-1.
	1 to SHA-1.
	KEY Protocol Values: [RFC2535] created an IANA Registry for KEY		KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
	Protocol Values, but [RFC3445] re-assigned all assigned values		Protocol Values, but [RFC3445] re-assigned all assigned values
	other than 3 to reserved and closed this IANA registry. The		other than 3 to reserved and closed this IANA registry. The
	registry remains closed, and all KEY and DNSKEY records are		registry remains closed, and all KEY and DNSKEY records are
	required to have Protocol Octet value of 3.		required to have Protocol Octet value of 3.
	Flag bits in the KEY and DNSKEY RRs:		Flag bits in the KEY and DNSKEY RRs:
	[I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA		[I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA
	registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,		registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
	this registry only contains an assignment for bit 7 (the ZONE bit)		this registry only contains an assignment for bit 7 (the ZONE bit)
	and a reservation for bit 15 for the Secure Entry Point flag (SEP		and a reservation for bit 15 for the Secure Entry Point flag (SEP
	bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14		bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14
	are available for assignment by IETF Standards Action.		are available for assignment by IETF Standards Action.
	Bit zero of Type Bit Map in NSEC RRs: The meaning of a value of 1 in
	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. Please see [I-D.ietf-dnsext-dnssec-intro]		security considerations. Please see [I-D.ietf-dnsext-dnssec-intro]
	and Please see [I-D.ietf-dnsext-dnssec-protocol] additional security		and [I-D.ietf-dnsext-dnssec-protocol] for additional security
	considerations related to the use of these records.		considerations related to the use of these records.
	The DS record points to a DNSKEY 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 DNSKEY RR, but it is theoretically possible for		identify an existing DNSKEY RR, but it is theoretically possible for
	an attacker to generate a DNSKEY 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 DNSKEY depends on the		probability of constructing such a matching DNSKEY depends on the
	type 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
	skipping to change at page 28, line 49 ¶		skipping to change at page 28, line 49 ¶
	[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain		[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
	Name System (DNS)", RFC 3110, May 2001.		Name System (DNS)", RFC 3110, May 2001.
	[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY		[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
	Resource Record (RR)", RFC 3445, December 2002.		Resource Record (RR)", RFC 3445, December 2002.
	[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record		[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
	(RR) Types", RFC 3597, September 2003.		(RR) Types", RFC 3597, September 2003.
	[I-D.ietf-dnsext-delegation-signer]		[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
	Gudmundsson, O., "Delegation Signer Resource Record",		(RR)", RFC 3658, December 2003.
	draft-ietf-dnsext-delegation-signer-15 (work in progress),
	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-07 (work in progress),		draft-ietf-dnsext-dnssec-intro-09 (work in progress),
	October 2003.		February 2004.
	[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-03 (work in		Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in
	progress), October 2003.		progress), February 2004.
	[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 Flag",		Entry Point Flag",
	draft-ietf-dnsext-keyrr-key-signing-flag-11 (work in		draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in
	progress), October 2003.		progress), December 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-05		Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06
	(work in progress), October 2003.		(work in progress), December 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
	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
	Rob Austein		Rob Austein
	Internet Software Consortium		Internet Systems Consortium
	40 Gavin Circle		950 Charter Street
	Reading, MA 01867		Redwood City, CA 94063
	USA		USA
	EMail: sra@isc.org		EMail: sra@isc.org
	Matt Larson		Matt Larson
	VeriSign, Inc.		VeriSign, Inc.
	21345 Ridgetop Circle		21345 Ridgetop Circle
	Dulles, VA 20166-6503		Dulles, VA 20166-6503
	USA		USA
	skipping to change at page 36, line 29 ¶		skipping to change at page 36, line 29 ¶
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 36 change blocks.
	74 lines changed or deleted		74 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/