< draft-ietf-dnsext-dnssec-protocol-08.txt		draft-ietf-dnsext-dnssec-protocol-09.txt >
	DNS Extensions R. Arends		DNS Extensions R. Arends
	Internet-Draft Telematica Instituut		Internet-Draft Telematica Instituut
	Expires: March 21, 2005 M. Larson		Expires: April 10, 2005 R. Austein
	VeriSign
	R. Austein
	ISC		ISC
			M. Larson
			VeriSign
	D. Massey		D. Massey
	USC/ISI		USC/ISI
	S. Rose		S. Rose
	NIST		NIST
	September 20, 2004		October 10, 2004
	Protocol Modifications for the DNS Security Extensions		Protocol Modifications for the DNS Security Extensions
	draft-ietf-dnsext-dnssec-protocol-08		draft-ietf-dnsext-dnssec-protocol-09
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any applicable patent or other IPR claims of
	which he or she is aware have been or will be disclosed, and any of		which he or she is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://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 21, 2005.		This Internet-Draft will expire on April 10, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This document is part of a family of documents which describe the DNS		This document is part of a family of documents which describe the DNS
	Security Extensions (DNSSEC). The DNS Security Extensions are a		Security Extensions (DNSSEC). The DNS Security Extensions are a
	collection of new resource records and protocol modifications which		collection of new resource records and protocol modifications which
	add data origin authentication and data integrity to the DNS. This		add data origin authentication and data integrity to the DNS. This
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10		3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10
	3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11		3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11
	3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11		3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11
	3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14		3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14
	3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15		3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15
	3.1.6 The AD and CD Bits in an Authoritative Response . . . 16		3.1.6 The AD and CD Bits in an Authoritative Response . . . 16
	3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17		3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17
	3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17		3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17
	3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17		3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17
	3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18		3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18
	3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18		3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 19
	4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19		4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19		4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20
	4.2 Signature Verification Support . . . . . . . . . . . . . . 19		4.2 Signature Verification Support . . . . . . . . . . . . . . 20
	4.3 Determining Security Status of Data . . . . . . . . . . . 20		4.3 Determining Security Status of Data . . . . . . . . . . . 21
	4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 21		4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 22
	4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21		4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22
	4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22		4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 23
	4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22		4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 23
	4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23		4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 24
	4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23		4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 24
	4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23		4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 24
	4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23		4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24
	4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24		4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 25
	5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25		5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 26
	5.1 Special Considerations for Islands of Security . . . . . . 26		5.1 Special Considerations for Islands of Security . . . . . . 27
	5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26		5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 27
	5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27		5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 28
	5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28		5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 29
	5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28		5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 29
	5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30		5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 31
	5.3.4 Authenticating A Wildcard Expanded RRset Positive		5.3.4 Authenticating A Wildcard Expanded RRset Positive
	Response . . . . . . . . . . . . . . . . . . . . . . . 31		Response . . . . . . . . . . . . . . . . . . . . . . . 32
	5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31		5.4 Authenticated Denial of Existence . . . . . . . . . . . . 32
	5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32		5.5 Resolver Behavior When Signatures Do Not Validate . . . . 33
	5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32		5.6 Authentication Example . . . . . . . . . . . . . . . . . . 33
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 34		7. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36		9.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
	9.2 Informative References . . . . . . . . . . . . . . . . . . . 37		9.2 Informative References . . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38
	A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39		A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 40
	B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45		B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 46
	B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45		B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 46
	B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46		B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 47
	B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47		B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 48
	B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48		B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 49
	B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49		B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 50
	B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50		B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 51
	B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51		B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 52
	B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52		B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 53
	C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54		C. Authentication Examples . . . . . . . . . . . . . . . . . . . 55
	C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54		C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 55
	C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54		C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 55
	C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55		C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 56
	C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55		C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 56
	C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55		C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 56
	C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55		C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 56
	C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56		C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 57
	C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56		C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 57
	C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56		C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 57
	Intellectual Property and Copyright Statements . . . . . . . . 57		Intellectual Property and Copyright Statements . . . . . . . . 58
	1. Introduction		1. Introduction
	The DNS Security Extensions (DNSSEC) are a collection of new resource		The DNS Security Extensions (DNSSEC) are a collection of new resource
	records and protocol modifications which add data origin		records and protocol modifications which add data origin
	authentication and data integrity to the DNS. This document defines		authentication and data integrity to the DNS. This document defines
	the DNSSEC protocol modifications. Section 2 of this document		the DNSSEC protocol modifications. Section 2 of this document
	defines the concept of a signed zone and lists the requirements for		defines the concept of a signed zone and lists the requirements for
	zone signing. Section 3 describes the modifications to authoritative		zone signing. Section 3 describes the modifications to authoritative
	name server behavior necessary to handle signed zones. Section 4		name server behavior necessary to handle signed zones. Section 4
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	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].
	2. Zone Signing		2. Zone Signing
	DNSSEC introduces the concept of signed zones. A signed zone		DNSSEC introduces the concept of signed zones. A signed zone
	includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to		includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
	the rules specified in Section 2.1, Section 2.2, Section 2.3 and		Next Secure (NSEC) and (optionally) Delegation Signer (DS) records
	Section 2.4, respectively. A zone that does not include these		according to the rules specified in Section 2.1, Section 2.2, Section
	records according to the rules in this section is an unsigned zone.		2.3 and Section 2.4, respectively. A zone that does not include
			these records according to the rules in this section is an unsigned
			zone.
	DNSSEC requires a change to the definition of the CNAME resource		DNSSEC requires a change to the definition of the CNAME resource
	record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG		record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG
	and NSEC RRs to appear at the same owner name as a CNAME RR.		and NSEC RRs to appear at the same owner name as a CNAME RR.
	DNSSEC specifies the placement of two new RR types, NSEC and DS,		DNSSEC specifies the placement of two new RR types, NSEC and DS,
	which can be placed at the parental side of a zone cut (that is, at a		which can be placed at the parental side of a zone cut (that is, at a
	delegation point). This is an exception to the general prohibition		delegation point). This is an exception to the general prohibition
	against putting data in the parent zone at a zone cut. Section 2.6		against putting data in the parent zone at a zone cut. Section 2.6
	describes this change.		describes this change.
	2.1 Including DNSKEY RRs in a Zone		2.1 Including DNSKEY RRs in a Zone
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 18 ¶
	security-aware name server functions. In many cases such functions		security-aware name server functions. In many cases such functions
	will be part of a security-aware recursive name server, but a		will be part of a security-aware recursive name server, but a
	security-aware authoritative name server has some of the same		security-aware authoritative name server has some of the same
	requirements. Functions specific to security-aware recursive name		requirements. Functions specific to security-aware recursive name
	servers are described in Section 3.2; functions specific to		servers are described in Section 3.2; functions specific to
	authoritative servers are described in Section 3.1.		authoritative servers are described in Section 3.1.
	The terms "SNAME", "SCLASS", and "STYPE" in the following discussion		The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
	are as used in [RFC1034].		are as used in [RFC1034].
	A security-aware name server MUST support the EDNS0 [RFC2671] message		A security-aware name server MUST support the EDNS0 ([RFC2671])
	size extension, MUST support a message size of at least 1220 octets,		message size extension, MUST support a message size of at least 1220
	and SHOULD support a message size of 4000 octets [RFC3226].		octets, and SHOULD support a message size of 4000 octets. Since IPv6
			packets can only be fragmented by the source host, a security aware
			name server SHOULD take steps to ensure that UDP datagrams it
			transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
			MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460],
			and [RFC3226] for further discussion of packet size and fragmentation
			issues.
	A security-aware name server which receives a DNS query that does not		A security-aware name server which receives a DNS query that does not
	include the EDNS OPT pseudo-RR or that has the DO bit clear MUST		include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
	treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset,		treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset,
	and MUST NOT perform any of the additional processing described		and MUST NOT perform any of the additional processing described
	below. Since the DS RR type has the peculiar property of only		below. Since the DS RR type has the peculiar property of only
	existing in the parent zone at delegation points, DS RRs always		existing in the parent zone at delegation points, DS RRs always
	require some special processing, as described in Section 3.1.4.1.		require some special processing, as described in Section 3.1.4.1.
	Security aware name servers that receive explicit queries for		Security aware name servers that receive explicit queries for
	skipping to change at page 10, line 11 ¶		skipping to change at page 10, line 17 ¶
	ignore the setting of the AD bit in queries. See Section 3.1.6,		ignore the setting of the AD bit in queries. See Section 3.1.6,
	Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details		Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
	on the behavior of these bits.		on the behavior of these bits.
	A security aware name server which synthesizes CNAME RRs from DNAME		A security aware name server which synthesizes CNAME RRs from DNAME
	RRs as described in [RFC2672] SHOULD NOT generate signatures for the		RRs as described in [RFC2672] SHOULD NOT generate signatures for the
	synthesized CNAME RRs.		synthesized CNAME RRs.
	3.1 Authoritative Name Servers		3.1 Authoritative Name Servers
	Upon receiving a relevant query that has the EDNS [RFC2671] OPT		Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
	pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name		pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
	server for a signed zone MUST include additional RRSIG, NSEC, and DS		server for a signed zone MUST include additional RRSIG, NSEC, and DS
	RRs according to the following rules:		RRs according to the following rules:
	o RRSIG RRs that can be used to authenticate a response MUST be		o RRSIG RRs that can be used to authenticate a response MUST be
	included in the response according to the rules in Section 3.1.1;		included in the response according to the rules in Section 3.1.1;
	o NSEC RRs that can be used to provide authenticated denial of		o NSEC RRs that can be used to provide authenticated denial of
	existence MUST be included in the response automatically according		existence MUST be included in the response automatically according
	to the rules in Section 3.1.3;		to the rules in Section 3.1.3;
	o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST		o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
	be included in referrals automatically according to the rules in		be included in referrals automatically according to the rules in
	Section 3.1.4.		Section 3.1.4.
	skipping to change at page 13, line 48 ¶		skipping to change at page 14, line 8 ¶
	which proves that no RRsets matching a particular SNAME exist.		which proves that no RRsets matching a particular SNAME exist.
	Locating such an NSEC RR within an authoritative zone is relatively		Locating such an NSEC RR within an authoritative zone is relatively
	simple, at least in concept. The following discussion assumes that		simple, at least in concept. The following discussion assumes that
	the name server is authoritative for the zone which would have held		the name server is authoritative for the zone which would have held
	the nonexistent RRsets matching SNAME. The algorithm below is		the nonexistent RRsets matching SNAME. The algorithm below is
	written for clarity, not efficiency.		written for clarity, not efficiency.
	To find the NSEC which proves that no RRsets matching name N exist in		To find the NSEC which proves that no RRsets matching name N exist in
	the zone Z which would have held them, construct sequence S		the zone Z which would have held them, construct sequence S
	consisting of the owner names of every RRset in Z, sorted into		consisting of the owner names of every RRset in Z, sorted into
	canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate		canonical order ([I-D.ietf-dnsext-dnssec-records]), with no duplicate
	names. Find the name M which would have immediately preceded N in S		names. Find the name M which would have immediately preceded N in S
	if any RRsets with owner name N had existed. M is the owner name of		if any RRsets with owner name N had existed. M is the owner name of
	the NSEC RR which proves that no RRsets exist with owner name N.		the NSEC RR which proves that no RRsets exist with owner name N.
	The algorithm for finding the NSEC RR which proves that a given name		The algorithm for finding the NSEC RR which proves that a given name
	is not covered by any applicable wildcard is similar, but requires an		is not covered by any applicable wildcard is similar, but requires an
	extra step. More precisely, the algorithm for finding the NSEC		extra step. More precisely, the algorithm for finding the NSEC
	proving that no RRsets exist with the applicable wildcard name is		proving that no RRsets exist with the applicable wildcard name is
	precisely the same as the algorithm for finding the NSEC RR which		precisely the same as the algorithm for finding the NSEC RR which
	proves that RRsets with any other owner name do not exist: the part		proves that RRsets with any other owner name do not exist: the part
	skipping to change at page 17, line 40 ¶		skipping to change at page 17, line 49 ¶
	3.2.2 The CD bit		3.2.2 The CD bit
	The CD bit exists in order to allow a security-aware resolver to		The CD bit exists in order to allow a security-aware resolver to
	disable signature validation in a security-aware name server's		disable signature validation in a security-aware name server's
	processing of a particular query.		processing of a particular query.
	The name server side MUST copy the setting of the CD bit from a query		The name server side MUST copy the setting of the CD bit from a query
	to the corresponding response.		to the corresponding response.
	The name server side of a security-aware recursive name server MUST		The name server side of a security-aware recursive name server MUST
	pass the sense of the CD bit to the resolver side along with the rest		pass the state of the CD bit to the resolver side along with the rest
	of an initiating query, so that the resolver side will know whether		of an initiating query, so that the resolver side will know whether
	or not it is required to verify the response data it returns to the		or not it is required to verify the response data it returns to the
	name server side. If the CD bit is set, it indicates that the		name server side. If the CD bit is set, it indicates that the
	originating resolver is willing to perform whatever authentication		originating resolver is willing to perform whatever authentication
	its local policy requires, thus the resolver side of the recursive		its local policy requires, thus the resolver side of the recursive
	name server need not perform authentication on the RRsets in the		name server need not perform authentication on the RRsets in the
	response. When the CD bit is set the recursive name server SHOULD,		response. When the CD bit is set the recursive name server SHOULD,
	if possible, return the requested data to the originating resolver		if possible, return the requested data to the originating resolver
	even if the recursive name server's local authentication policy would		even if the recursive name server's local authentication policy would
	reject the records in question. That is, by setting the CD bit, the		reject the records in question. That is, by setting the CD bit, the
	originating resolver has indicated that it takes responsibility for		originating resolver has indicated that it takes responsibility for
	performing its own authentication, and the recursive name server		performing its own authentication, and the recursive name server
	should not interfere.		should not interfere.
	If the resolver side implements a BAD cache (see Section 4.7) and the		If the resolver side implements a BAD cache (see Section 4.7) and the
	name server side receives a query which matches an entry in the		name server side receives a query which matches an entry in the
	resolver side's BAD cache, the name server side's response depends on		resolver side's BAD cache, the name server side's response depends on
	the sense of the CD bit in the original query. If the CD bit is set,		the state of the CD bit in the original query. If the CD bit is set,
	the name server side SHOULD return the data from the BAD cache; if		the name server side SHOULD return the data from the BAD cache; if
	the CD bit is not set, the name server side MUST return RCODE 2		the CD bit is not set, the name server side MUST return RCODE 2
	(server failure).		(server failure).
	The intent of the above rule is to provide the raw data to clients		The intent of the above rule is to provide the raw data to clients
	which are capable of performing their own signature verification		which are capable of performing their own signature verification
	checks while protecting clients which depend on the resolver side of		checks while protecting clients which depend on the resolver side of
	a security-aware recursive name server to perform such checks.		a security-aware recursive name server to perform such checks.
	Several of the possible reasons why signature validation might fail		Several of the possible reasons why signature validation might fail
	involve conditions which may not apply equally to the recursive name		involve conditions which may not apply equally to the recursive name
	skipping to change at page 19, line 16 ¶		skipping to change at page 20, line 16 ¶
	This section describes the behavior of entities that include		This section describes the behavior of entities that include
	security-aware resolver functions. In many cases such functions will		security-aware resolver functions. In many cases such functions will
	be part of a security-aware recursive name server, but a stand-alone		be part of a security-aware recursive name server, but a stand-alone
	security-aware resolver has many of the same requirements. Functions		security-aware resolver has many of the same requirements. Functions
	specific to security-aware recursive name servers are described in		specific to security-aware recursive name servers are described in
	Section 3.2.		Section 3.2.
	4.1 EDNS Support		4.1 EDNS Support
	A security-aware resolver MUST include an EDNS [RFC2671] OPT		A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
	pseudo-RR with the DO [RFC3225] bit set when sending queries.		pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
	A security-aware resolver MUST support a message size of at least		A security-aware resolver MUST support a message size of at least
	1220 octets, SHOULD support a message size of 4000 octets, and MUST		1220 octets, SHOULD support a message size of 4000 octets, and MUST
	advertise the supported message size using the "sender's UDP payload		advertise the message size it's willing to accept using the "sender's
	size" field in the EDNS OPT pseudo-RR. A security-aware resolver's		UDP payload size" field in the EDNS OPT pseudo-RR. A security-aware
	IP layer MUST handle fragmented UDP packets correctly regardless of		resolver's IP layer MUST handle fragmented UDP packets correctly
	whether any such fragmented packets were received via IPv4 or IPv6.		regardless of whether any such fragmented packets were received via
	Please see [RFC1122], [RFC2460] and [RFC3226] for discussion of these		IPv4 or IPv6. Please see [RFC1122], [RFC2460] and [RFC3226] for
	requirements.		discussion of these requirements.
	4.2 Signature Verification Support		4.2 Signature Verification Support
	A security-aware resolver MUST support the signature verification		A security-aware resolver MUST support the signature verification
	mechanisms described in Section 5, and SHOULD apply them to every		mechanisms described in Section 5, and SHOULD apply them to every
	received response except when:		received response except when:
	o The security-aware resolver is part of a security-aware recursive		o The security-aware resolver is part of a security-aware recursive
	name server, and the response is the result of recursion on behalf		name server, and the response is the result of recursion on behalf
	of a query received with the CD bit set;		of a query received with the CD bit set;
	o The response is the result of a query generated directly via some		o The response is the result of a query generated directly via some
	skipping to change at page 20, line 16 ¶		skipping to change at page 21, line 16 ¶
	When attempting to retrieve a missing DS, a security-aware		When attempting to retrieve a missing DS, a security-aware
	iterative-mode resolver MUST query the name servers for the parent		iterative-mode resolver MUST query the name servers for the parent
	zone, not the child zone. As explained in Section 3.1.4.1,		zone, not the child zone. As explained in Section 3.1.4.1,
	security-aware name servers need to apply special processing rules to		security-aware name servers need to apply special processing rules to
	handle the DS RR, and in some situations the resolver may also need		handle the DS RR, and in some situations the resolver may also need
	to apply special rules to locate the name servers for the parent zone		to apply special rules to locate the name servers for the parent zone
	if the resolver does not already have the parent's NS RRset. To		if the resolver does not already have the parent's NS RRset. To
	locate the parent NS RRset, the resolver can start with the		locate the parent NS RRset, the resolver can start with the
	delegation name, strip off the leftmost label, and query for an NS		delegation name, strip off the leftmost label, and query for an NS
	RRset by that name; if no NS RRset is present at that name, the		RRset by that name; if no NS RRset is present at that name, the
	resolver then strips of the leftmost remaining label and retries the		resolver then strips off the leftmost remaining label and retries the
	query for that name, repeating this process of walking up the tree		query for that name, repeating this process of walking up the tree
	until it either finds the NS RRset or runs out of labels.		until it either finds the NS RRset or runs out of labels.
	4.3 Determining Security Status of Data		4.3 Determining Security Status of Data
	A security-aware resolver MUST be able to determine whether or not it		A security-aware resolver MUST be able to determine whether or not it
	should expect a particular RRset to be signed. More precisely, a		should expect a particular RRset to be signed. More precisely, a
	security-aware resolver must be able to distinguish between four		security-aware resolver must be able to distinguish between four
	cases:		cases:
	skipping to change at page 22, line 35 ¶		skipping to change at page 23, line 35 ¶
	While many validation errors will be transient, some are likely to be		While many validation errors will be transient, some are likely to be
	more persistent, such as those caused by administrative error		more persistent, such as those caused by administrative error
	(failure to re-sign a zone, clock skew, and so forth). Since		(failure to re-sign a zone, clock skew, and so forth). Since
	requerying will not help in these cases, validating resolvers might		requerying will not help in these cases, validating resolvers might
	generate a significant amount of unnecessary DNS traffic as a result		generate a significant amount of unnecessary DNS traffic as a result
	of repeated queries for RRsets with persistent validation failures.		of repeated queries for RRsets with persistent validation failures.
	To prevent such unnecessary DNS traffic, security-aware resolvers MAY		To prevent such unnecessary DNS traffic, security-aware resolvers MAY
	cache data with invalid signatures, with some restrictions.		cache data with invalid signatures, with some restrictions.
	Conceptually, caching such data is similar to negative caching		Conceptually, caching such data is similar to negative caching
	[RFC2308], except that instead of caching a valid negative response,		([RFC2308]), except that instead of caching a valid negative
	the resolver is caching the fact that a particular answer failed to		response, the resolver is caching the fact that a particular answer
	validate. This document refers to a cache of data with invalid		failed to validate. This document refers to a cache of data with
	signatures as a "BAD cache".		invalid signatures as a "BAD cache".
	Resolvers which implement a BAD cache MUST take steps to prevent the		Resolvers which implement a BAD cache MUST take steps to prevent the
	cache from being useful as a denial-of-service attack amplifier. In		cache from being useful as a denial-of-service attack amplifier. In
	particular:		particular:
	o Since RRsets which fail to validate do not have trustworthy TTLs,		o Since RRsets which fail to validate do not have trustworthy TTLs,
	the implementation MUST assign a TTL. This TTL SHOULD be small,		the implementation MUST assign a TTL. This TTL SHOULD be small,
	in order to mitigate the effect of caching the results of an		in order to mitigate the effect of caching the results of an
	attack.		attack.
	o In order to prevent caching of a transient validation failure		o In order to prevent caching of a transient validation failure
	(which might be the result of an attack), resolvers SHOULD track		(which might be the result of an attack), resolvers SHOULD track
	skipping to change at page 26, line 36 ¶		skipping to change at page 27, line 36 ¶
	security. The only difference between normal validation and		security. The only difference between normal validation and
	validation within an island of security is in how the validator		validation within an island of security is in how the validator
	obtains a trust anchor for the authentication chain.		obtains a trust anchor for the authentication chain.
	5.2 Authenticating Referrals		5.2 Authenticating Referrals
	Once the apex DNSKEY RRset for a signed parent zone has been		Once the apex DNSKEY RRset for a signed parent zone has been
	authenticated, DS RRsets can be used to authenticate the delegation		authenticated, DS RRsets can be used to authenticate the delegation
	to a signed child zone. A DS RR identifies a DNSKEY RR in the child		to a signed child zone. A DS RR identifies a DNSKEY RR in the child
	zone's apex DNSKEY RRset, and contains a cryptographic digest of the		zone's apex DNSKEY RRset, and contains a cryptographic digest of the
	child zone's DNSKEY RR. A strong cryptographic digest algorithm		child zone's DNSKEY RR. Use of a strong cryptographic digest
	ensures that an adversary can not easily generate a DNSKEY RR that		algorithm ensures that it is computationally infeasible for an
	matches the digest. Thus, authenticating the digest allows a		adversary to generate a DNSKEY RR that matches the digest. Thus,
	resolver to authenticate the matching DNSKEY RR. The resolver can		authenticating the digest allows a resolver to authenticate the
	then use this child DNSKEY RR to authenticate the entire child apex		matching DNSKEY RR. The resolver can then use this child DNSKEY RR
	DNSKEY RRset.		to authenticate the entire child apex DNSKEY RRset.
	Given a DS RR for a delegation, the child zone's apex DNSKEY RRset		Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
	can be authenticated if all of the following hold:		can be authenticated if all of the following hold:
	o The DS RR has been authenticated using some DNSKEY RR in the		o The DS RR has been authenticated using some DNSKEY RR in the
	parent's apex DNSKEY RRset (see Section 5.3);		parent's apex DNSKEY RRset (see Section 5.3);
	o The Algorithm and Key Tag in the DS RR match the Algorithm field		o The Algorithm and Key Tag in the DS RR match the Algorithm field
	and the key tag of a DNSKEY RR in the child zone's apex DNSKEY		and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
	RRset and, when the DNSKEY RR's owner name and RDATA are hashed		RRset and, when the DNSKEY RR's owner name and RDATA are hashed
	using the digest algorithm specified in the DS RR's Digest Type		using the digest algorithm specified in the DS RR's Digest Type
	field, the resulting digest value matches the Digest field of the		field, the resulting digest value matches the Digest field of the
	skipping to change at page 32, line 48 ¶		skipping to change at page 33, line 48 ¶
	If for whatever reason none of the RRSIGs can be validated, the		If for whatever reason none of the RRSIGs can be validated, the
	response SHOULD be considered BAD. If the validation was being done		response SHOULD be considered BAD. If the validation was being done
	to service a recursive query, the name server MUST return RCODE 2 to		to service a recursive query, the name server MUST return RCODE 2 to
	the originating client. However, it MUST return the full response if		the originating client. However, it MUST return the full response if
	and only if the original query had the CD bit set. See also Section		and only if the original query had the CD bit set. See also Section
	4.7 on caching responses that do not validate.		4.7 on caching responses that do not validate.
	5.6 Authentication Example		5.6 Authentication Example
	Appendix C shows an example the authentication process.		Appendix C shows an example of the authentication process.
	6. IANA Considerations		6. IANA Considerations
	[I-D.ietf-dnsext-dnssec-records] contains a review of the IANA		[I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
	considerations introduced by DNSSEC. The additional IANA		considerations introduced by DNSSEC. The additional IANA
	considerations discussed in this document:		considerations discussed in this document:
	[RFC2535] reserved the CD and AD bits in the message header. The		[RFC2535] reserved the CD and AD bits in the message header. The
	meaning of the AD bit was redefined in [RFC3655] and the meaning of		meaning of the AD bit was redefined in [RFC3655] and the meaning of
	both the CD and AD bit are restated in this document. No new bits in		both the CD and AD bit are restated in this document. No new bits in
	skipping to change at page 37, line 41 ¶		skipping to change at page 38, line 41 ¶
	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
	Matt Larson
	VeriSign, Inc.
	21345 Ridgetop Circle
	Dulles, VA 20166-6503
	USA
	EMail: mlarson@verisign.com
	Rob Austein		Rob Austein
	Internet Systems Consortium		Internet Systems Consortium
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	USA		USA
	EMail: sra@isc.org		EMail: sra@isc.org
			Matt Larson
			VeriSign, Inc.
			21345 Ridgetop Circle
			Dulles, VA 20166-6503
			USA
			EMail: mlarson@verisign.com
	Dan Massey		Dan Massey
	USC Information Sciences Institute		USC Information Sciences Institute
	3811 N. Fairfax Drive		3811 N. Fairfax Drive
	Arlington, VA 22203		Arlington, VA 22203
	USA		USA
	EMail: masseyd@isi.edu		EMail: masseyd@isi.edu
	Scott Rose		Scott Rose
	skipping to change at page 54, line 12 ¶		skipping to change at page 55, line 12 ¶
	;; Additional		;; Additional
	;; (empty)		;; (empty)
	Appendix C. Authentication Examples		Appendix C. Authentication Examples
	The examples in this section show how the response messages in		The examples in this section show how the response messages in
	Appendix B are authenticated.		Appendix B are authenticated.
	C.1 Authenticating An Answer		C.1 Authenticating An Answer
	The query in section Appendix B.1 returned an MX RRset for		The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
	"x.w.example.com". The corresponding RRSIG indicates the MX RRset		The corresponding RRSIG indicates the MX RRset was signed by an
	was signed by an "example" DNSKEY with algorithm 5 and key tag 38519.		"example" DNSKEY with algorithm 5 and key tag 38519. The resolver
	The resolver needs the corresponding DNSKEY RR in order to		needs the corresponding DNSKEY RR in order to authenticate this
	authenticate this answer. The discussion below describes how a		answer. The discussion below describes how a resolver might obtain
	resolver might obtain this DNSKEY RR.		this DNSKEY RR.
	The RRSIG indicates the original TTL of the MX RRset was 3600 and,		The RRSIG indicates the original TTL of the MX RRset was 3600 and,
	for the purpose of authentication, the current TTL is replaced by		for the purpose of authentication, the current TTL is replaced by
	3600. The RRSIG labels field value of 3 indicates the answer was not		3600. The RRSIG labels field value of 3 indicates the answer was not
	the result of wildcard expansion. The "x.w.example.com" MX RRset is		the result of wildcard expansion. The "x.w.example.com" MX RRset is
	placed in canonical form and, assuming the current time falls between		placed in canonical form and, assuming the current time falls between
	the signature inception and expiration dates, the signature is		the signature inception and expiration dates, the signature is
	authenticated.		authenticated.
	C.1.1 Authenticating the example DNSKEY RR		C.1.1 Authenticating the example DNSKEY RR
	skipping to change at page 55, line 19 ¶		skipping to change at page 56, line 19 ¶
	Finally the resolver checks that some DNSKEY RR in the "example"		Finally the resolver checks that some DNSKEY RR in the "example"
	DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This		DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This
	DNSKEY is used to authenticated the RRSIG included in the response.		DNSKEY is used to authenticated the RRSIG included in the response.
	If multiple "example" DNSKEY RRs match this algorithm and key tag,		If multiple "example" DNSKEY RRs match this algorithm and key tag,
	then each DNSKEY RR is tried and the answer is authenticated if any		then each DNSKEY RR is tried and the answer is authenticated if any
	of the matching DNSKEY RRs validates the signature as described		of the matching DNSKEY RRs validates the signature as described
	above.		above.
	C.2 Name Error		C.2 Name Error
	The query in section Appendix B.2 returned NSEC RRs that prove the		The query in Appendix B.2 returned NSEC RRs that prove the requested
	requested data does not exist and no wildcard applies. The negative		data does not exist and no wildcard applies. The negative reply is
	reply is authenticated by verifying both NSEC RRs. The NSEC RRs are		authenticated by verifying both NSEC RRs. The NSEC RRs are
	authenticated in a manner identical to that of the MX RRset discussed		authenticated in a manner identical to that of the MX RRset discussed
	above.		above.
	C.3 No Data Error		C.3 No Data Error
	The query in section Appendix B.3 returned an NSEC RR that proves the		The query in Appendix B.3 returned an NSEC RR that proves the
	requested name exists, but the requested RR type does not exist. The		requested name exists, but the requested RR type does not exist. The
	negative reply is authenticated by verifying the NSEC RR. The NSEC		negative reply is authenticated by verifying the NSEC RR. The NSEC
	RR is authenticated in a manner identical to that of the MX RRset		RR is authenticated in a manner identical to that of the MX RRset
	discussed above.		discussed above.
	C.4 Referral to Signed Zone		C.4 Referral to Signed Zone
	The query in section Appendix B.4 returned a referral to the signed		The query in Appendix B.4 returned a referral to the signed
	"a.example." zone. The DS RR is authenticated in a manner identical		"a.example." zone. The DS RR is authenticated in a manner identical
	to that of the MX RRset discussed above. This DS RR is used to		to that of the MX RRset discussed above. This DS RR is used to
	authenticate the "a.example" DNSKEY RRset.		authenticate the "a.example" DNSKEY RRset.
	Once the "a.example" DS RRset has been authenticated using the		Once the "a.example" DS RRset has been authenticated using the
	"example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset		"example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
	for some "a.example" DNSKEY RR that matches the DS RR. If such a		for some "a.example" DNSKEY RR that matches the DS RR. If such a
	matching "a.example" DNSKEY is found, the resolver checks this DNSKEY		matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
	RR has signed the "a.example" DNSKEY RRset and the signature lifetime		RR has signed the "a.example" DNSKEY RRset and the signature lifetime
	is valid. If all these conditions are met, all keys in the		is valid. If all these conditions are met, all keys in the
	"a.example" DNSKEY RRset are considered authenticated.		"a.example" DNSKEY RRset are considered authenticated.
	C.5 Referral to Unsigned Zone		C.5 Referral to Unsigned Zone
	The query in section Appendix B.5 returned a referral to an unsigned		The query in Appendix B.5 returned a referral to an unsigned
	"b.example." zone. The NSEC proves that no authentication leads from		"b.example." zone. The NSEC proves that no authentication leads from
	"example" to "b.example" and the NSEC RR is authenticated in a manner		"example" to "b.example" and the NSEC RR is authenticated in a manner
	identical to that of the MX RRset discussed above.		identical to that of the MX RRset discussed above.
	C.6 Wildcard Expansion		C.6 Wildcard Expansion
	The query in section Appendix B.6 returned an answer that was		The query in Appendix B.6 returned an answer that was produced as a
	produced as a result of wildcard expansion. The answer section		result of wildcard expansion. The answer section contains a wildcard
	contains a wildcard RRset expanded as in a traditional DNS response		RRset expanded as in a traditional DNS response and the corresponding
	and the corresponding RRSIG indicates that the expanded wildcard MX		RRSIG indicates that the expanded wildcard MX RRset was signed by an
	RRset was signed by an "example" DNSKEY with algorithm 5 and key tag		"example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG
	38519. The RRSIG indicates the original TTL of the MX RRset was 3600		indicates the original TTL of the MX RRset was 3600 and, for the
	and, for the purpose of authentication, the current TTL is replaced		purpose of authentication, the current TTL is replaced by 3600. The
	by 3600. The RRSIG labels field value of 2 indicates the answer the		RRSIG labels field value of 2 indicates the answer the result of
	result of wildcard expansion since the "a.z.w.example" name contains		wildcard expansion since the "a.z.w.example" name contains 4 labels.
	4 labels. The name "a.z.w.w.example" is replaced by "*.w.example",		The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset
	the MX RRset is placed in canonical form and, assuming the current		is placed in canonical form and, assuming the current time falls
	time falls between the signature inception and expiration dates, the		between the signature inception and expiration dates, the signature
	signature is authenticated.		is authenticated.
	The NSEC proves that no closer match (exact or closer wildcard) could		The NSEC proves that no closer match (exact or closer wildcard) could
	have been used to answer this query and the NSEC RR must also be		have been used to answer this query and the NSEC RR must also be
	authenticated before the answer is considered valid.		authenticated before the answer is considered valid.
	C.7 Wildcard No Data Error		C.7 Wildcard No Data Error
	The query in section Appendix B.7 returned NSEC RRs that prove the		The query in Appendix B.7 returned NSEC RRs that prove the requested
	requested data does not exist and no wildcard applies. The negative		data does not exist and no wildcard applies. The negative reply is
	reply is authenticated by verifying both NSEC RRs.		authenticated by verifying both NSEC RRs.
	C.8 DS Child Zone No Data Error		C.8 DS Child Zone No Data Error
	The query in section Appendix B.8 returned NSEC RRs that shows the		The query in Appendix B.8 returned NSEC RRs that shows the requested
	requested was answered by a child server ("example" server). The		was answered by a child server ("example" server). The NSEC RR
	NSEC RR indicates the presence of an SOA RR, showing the answer is		indicates the presence of an SOA RR, showing the answer is from the
	from the child . Queries for the "example" DS RRset should be sent		child . Queries for the "example" DS RRset should be sent to the
	to the parent servers ("root" servers).		parent servers ("root" servers).
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes. 30 change blocks.
	132 lines changed or deleted		140 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/