< draft-ietf-dnsext-dnssec-records-05.txt		draft-ietf-dnsext-dnssec-records-06.txt >
	DNS Extensions R. Arends		DNS Extensions R. Arends
	Internet-Draft Telematica Instituut		Internet-Draft Telematica Instituut
	Expires: April 26, 2004 R. Austein		Expires: June 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
	October 27, 2003		December 17, 2003
	Resource Records for the DNS Security Extensions		Resource Records for the DNS Security Extensions
	draft-ietf-dnsext-dnssec-records-05		draft-ietf-dnsext-dnssec-records-06
	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 April 26, 2004.		This Internet-Draft will expire on June 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
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7		2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7
	2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8		2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . . . . . . . 12
	3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12		3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12
	3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 12		3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13
	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 Maps Field . . . . . . . . . . . . . . . . . . 16
	4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 16		4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 17
	4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 16		4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 17
	4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17		4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17
	5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18		5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 19
	5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18		5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 19
	5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 19		5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 20
	5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19		5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 20
	5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19		5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 20
	5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19		5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 20
	5.2 Processing of DS RRs When Validating Responses . . . . . . . 19		5.2 Processing of DS RRs When Validating Responses . . . . . . . 20
	5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 20		5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 21
	5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20		5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 21
	6. Canonical Form and Order of Resource Records . . . . . . . . 21		6. Canonical Form and Order of Resource Records . . . . . . . . 22
	6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21		6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 22
	6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21		6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 22
	6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22		6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 23
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
	8. Security Considerations . . . . . . . . . . . . . . . . . . 25		8. Security Considerations . . . . . . . . . . . . . . . . . . 26
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27
	Normative References . . . . . . . . . . . . . . . . . . . . 27		Normative References . . . . . . . . . . . . . . . . . . . . 28
	Informative References . . . . . . . . . . . . . . . . . . . 29		Informative References . . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
	A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 31		A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 32
	A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 31		A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 32
	A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 31		A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 32
	A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 32		A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33
	B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 33		B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34
	B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 34		B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35
	Intellectual Property and Copyright Statements . . . . . . . 35		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.		ASCII representation.
	1.1 Background and Related Documents		1.1 Background and Related Documents
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 22 ¶
	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.
	An 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.
			Because every authoritative RRset in a zone must be protected by a
			digital signature, RRSIG RRs must be present for names containing a
			CNAME RR. 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 allowed at that name. A RRSIG and NSEC (see Section 4)
			MUST exist for the same name as a CNAME resource record in a secure
			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.		it covers. This is an exception to the [RFC2181] rules for TTL
			values of individuals RRs within a RRset: individual RRSIG with the
			same owner name will have different TTLs if the RRsets that they
			cover have different TTLs.
	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 15, line 16 ¶		skipping to change at page 15, line 16 ¶
	The NSEC 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 NSEC RR's owner name. The		and the set of RR types present at the NSEC RR's owner name. The
	complete set of NSEC 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		denial of existence for DNS data, as described in
	[I-D.ietf-dnsext-dnssec-protocol].		[I-D.ietf-dnsext-dnssec-protocol].
			Because every authoritative name in a zone must be part of the NSEC
			chain, NSEC RRs must be present for names containing a CNAME RR.
			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
			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.
	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 has no special TTL requirements.
	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 Map /		/ 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 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 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 Maps Field
	The Type Bit Map field identifies the RRset types which exist at the		The Type Bit Maps 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		The RR type space is split into 256 window blocks, each representing
	corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS),		the low-order 8 bits of the 16-bit RR type space. Each block that has
	and so forth. If a bit is set to 1, it indicates that an RRset of		at least one active RR type is encoded using a single octet window
	that type is present for the NSEC RR's owner name. If a bit is set to		number (from 0 to 255), a single octet bitmap length (from 1 to 32)
	0, it indicates that no RRset of that type present for the NSEC RR's		indicating the number of octets used for the window block's bitmap,
	owner name.		and up to 32 octets (256 bits) of bitmap.
	A zone MUST NOT generate an NSEC RR for any domain name that only		Blocks are present in the NSEC RR RDATA in increasing numerical
	holds glue records.		order.
	Bits representing pseudo-RR types MUST be set to 0, since they do not		Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
	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		where "|" denotes concatenation.
	field varies, and is determined by the type code with the largest
	numerical value among the set of RR types present at the NSEC RR's
	owner name. Trailing zero octets not specified MUST be interpreted
	as zero octets.
	The above Type Bit Map format MUST NOT be used when an RR type code		Each bitmap encodes the low-order 8 bits of RR types within the
	with numerical value greater than 127 is present.		window block, in network bit order. The first bit is bit 0. For
			window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
			to RR type 2 (NS), and so forth. For window block 1, bit 1
			corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
			1, it indicates that an RRset of that type is present for the NSEC
			RR's owner name. If a bit is set to 0, it indicates that no RRset of
			that type is present for the NSEC RR's owner name.
	Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A		Since bit 0 in window block 0 refers to the non-existent RR type 0,
	value of 0 in bit 0 denotes the format described above, therefore bit		it MUST be set to 0. After verification, the validator MUST ignore
	0 MUST have a value of 0. The format and meaning of a Type Bit Map		the value of bit 0 in window block 0.
	with a value of 1 in bit 0 is undefined.
			Bits representing pseudo-types MUST be set to 0, since they do not
			appear in zone data. If encountered, they MUST be ignored upon
			reading.
			Blocks with no types present MUST NOT be included. Trailing zero
			octets in the bitmap MUST be omitted. The length of each block's
			bitmap is determined by the type code with the largest numerical
			value, within that block, among the set of RR types present at the
			NSEC RR's owner name. Trailing zero octets not specified MUST be
			interpreted as zero octets.
			A zone MUST NOT generate an NSEC RR for any domain name that only
			holds glue records.
	4.1.3 Inclusion of Wildcard Names in NSEC 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 NSEC 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.
	[I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards		[I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards
	on authenticated denial of existence.		on authenticated denial of existence.
	4.2 The NSEC 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 Maps field is represented as a sequence of RR type
	mnemonics or as a sequence of unsigned decimal integers denoting the		mnemonics. When the mnemonic is not known, the TYPE representation
	RR type codes.		as described in [RFC3597] (section 5) MUST be used.
	4.3 NSEC RR Example		4.3 NSEC RR Example
	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. A MX RRSIG NSEC		alfa.example.com. 86400 IN NSEC host.example.com. (
			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 and NSEC
	mnemonics indicate there are A, MX, RRSIG and NSEC RRsets associated		mnemonics indicate there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets
	with the name alfa.example.com.		associated with the name alfa.example.com.
			The RDATA section of the NSEC RR above would be encoded as:
			0x04 'h' 'o' 's' 't'
			0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
			0x03 'c' 'o' 'm' 0x00
			0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
			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 0x20
	Assuming that the resolver can authenticate this NSEC record, it		Assuming that the resolver can authenticate this NSEC record, 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
	storing the key tag and key algorithm helps make the identification		public key, storing the key tag and key algorithm helps make the
	process more efficient. By authenticating the DS record, a resolver		identification process more efficient. By authenticating the DS
	can authenticate the DNSKEY RR to which the DS record points. The		record, a resolver can authenticate the DNSKEY RR to which the DS
	key authentication process is described in		record points. The key authentication process is described in
	[I-D.ietf-dnsext-dnssec-protocol].		[I-D.ietf-dnsext-dnssec-protocol].
	The DS RR and its corresponding DNSKEY RR have the same owner name,		The DS RR and its corresponding DNSKEY RR have the same owner name,
	but they are stored in different locations. The DS RR appears only		but they are stored in different locations. The DS RR appears only
	on the upper (parental) side of a delegation, and is authoritative		on the upper (parental) side of a delegation, and is authoritative
	data 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 DNSKEY 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
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 29 ¶
	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 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.
			[RFC2181] specifies that an RRset is not allowed to contain duplicate
			records (multiple RRs with the same owner name, class, type, and
			RDATA). Therefore, if an implementation detects duplicate RRs during
			RRset canonicalization, the implementation MUST treat this as a
			protocol error. If the implementation chooses to handle this
			protocol error in the spirit of the robustness principle (being
			liberal in what it accepts), the implementation MUST remove all but
			one of the duplicate RR(s) for purposes of calculating the canonical
			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.
	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.
	[I-D.ietf-dnsext-delegation-signer] assigned DNS Resource Record		[I-D.ietf-dnsext-delegation-signer] assigned DNS Resource Record
	Type 43 to DS. [I-D.ietf-dnsext-dnssec-2535typecode-change]		Type 43 to DS. [I-D.ietf-dnsext-dnssec-2535typecode-change]
	assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,		assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,
	respectively. [I-D.ietf-dnsext-dnssec-2535typecode-change] also		respectively. [I-D.ietf-dnsext-dnssec-2535typecode-change] also
	marked type 30 (NXT) as Obsolete, and restricted use of types 24		marked type 30 (NXT) as Obsolete, and restricted use of types 24
	(SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol		(SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol
	described in [RFC2931].		described in [RFC2931].
	SIG(0) Algorithm Numbers: [RFC2535] created an IANA registry for		DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
	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] renamed this registry		[I-D.ietf-dnsext-dnssec-2535typecode-change] altered this registry
	to "SIG(0) Algorithm Numbers" to indicate that this registry is		to include flags for each entry regarding its use with the DNS
	now used only by the "SIG(0)" transaction security protocol		security extensions. Each algorithm entry could refer to an
	described in [RFC2931].		algorithm that can be used for zone signing, transaction security
			(see [RFC2931]) or both. Values 6-251 are available for assignment
	DNS Security Algorithm Numbers:		by IETF standards action. See Appendix A for a full listing of the
	[I-D.ietf-dnsext-dnssec-2535typecode-change] created a new "DNS		DNS Security Algorithm Numbers entries at the time of writing and
	Security Algorithm Numbers" registry, assigned initial values to		their status of use in DNSSEC.
	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.
	[I-D.ietf-dnsext-delegation-signer] created an IANA registry for		[I-D.ietf-dnsext-delegation-signer] created an IANA registry for
	DNSSEC DS Digest Types, and assigned value 0 to reserved and value		DNSSEC DS Digest Types, and 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: The Flag bits in the KEY and		Flag bits in the KEY and DNSKEY RRs:
	DNSKEY RRs are not assigned by IANA, and there is no IANA registry		[I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA
	for these flags. All changes to the meaning of the Flag bits in		registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
	the KEY and DNSKEY RRs require a standards action.		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
			bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14
			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 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		bit zero of the Type Bit Map of an NSEC RR can only be assigned by
	a standards action.		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. Please see [I-D.ietf-dnsext-dnssec-intro]
	separate document, and security considerations related to the use		and Please see [I-D.ietf-dnsext-dnssec-protocol] additional security
	these resource records are discussed in that document.		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
	digest given in a DS record would be a sufficiently difficult problem		digest given in a DS record would be a sufficiently difficult problem
	skipping to change at page 26, line 7 ¶		skipping to change at page 27, line 7 ¶
	The key tag is used to help select DNSKEY resource records		The key tag is used to help select DNSKEY resource records
	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 the members of
	of the DNS Extensions Working Group and working group mailing list.		the DNS Extensions Working Group and working group mailing list. The
	The editors would like to express their thanks for the comments and		editors would like to express their thanks for the comments and
	suggestions received during the revision of these security extension		suggestions received during the revision of these security extension
	specifications.		specifications. While explicitly listing everyone who has
			contributed during the decade during which DNSSEC has been under
			development would be an impossible task,
			[I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
			participants who were kind enough to comment on these documents.
	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 31, line 22 ¶		skipping to change at page 32, line 22 ¶
	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 DNSKEY, RRSIG, and DS resource		The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify
	record types identifies the cryptographic algorithm used by the		the security algorithm being used. These values are stored in the
	resource record. Algorithm specific formats are described in		"Algorithm number" field in the resource record RDATA.
	separate documents. The following table lists the currently defined
	algorithm types and provides references to their supporting
	documents:
	VALUE Algorithm [mnemonic] RFC STATUS		Some algorithms are usable only for zone signing (DNSSEC), some only
	0 Reserved - -		for transaction security mechanisms (SIG(0) and TSIG), and some for
	1 RSA/MD5 [RSA/MD5] RFC 2537 NOT RECOMMENDED		both. Those usable for zone signing may appear in DNSKEY, RRSIG, and
	2 Diffie-Hellman [DH] RFC 2539 OPTIONAL		DS RRs. Those usable for transaction security would be present in
	3 DSA [DSA] RFC 2536 OPTIONAL		SIG(0) and KEY RRs as described in [RFC2931]
	4 elliptic curve [ECC] TBA OPTIONAL
	5 RSA/SHA1 [RSA/SHA1] RFC 3110 MANDATORY		Zone
	6-251 available for assignment -		Value Algorithm [Mnemonic] Signing References Status
	252 reserved -		----- -------------------- --------- ---------- ---------
	253 private [PRIVATE_DNS] see below OPTIONAL		0 reserved
	254 private [PRIVATE_OID] see below OPTIONAL		1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED
	255 reserved - -		2 Diffie-Hellman [DH] n RFC 2539 -
			3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL
			4 Elliptic Curve [ECC] TBA -
			5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY
			252 Indirect [INDIRECT] n -
			253 Private [PRIVATEDNS] y see below OPTIONAL
			254 Private [PRIVATEOID] y see below OPTIONAL
			255 reserved
			6 - 251 Available for assignment by IETF Standards Action.
	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 DNSKEY		assigned to a specific algorithm. The public key area in the DNSKEY
	RR and the signature area in the RRSIG RR begin with a wire encoded		RR and the signature area in the RRSIG RR begin with a wire encoded
	domain name, which MUST NOT be compressed. The domain name indicates		domain name, which MUST NOT be compressed. The domain name indicates
	the private algorithm to use and the remainder of the public key area		the private algorithm to use and the remainder of the public key area
	is determined by that algorithm. Entities should only use domain		is determined by that algorithm. Entities should only use domain
	names they control to designate their private algorithms.		names they control to designate their private algorithms.
End of changes. 33 change blocks.
	116 lines changed or deleted		177 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/