< draft-ietf-dnsext-dnssec-records-09.txt		draft-ietf-dnsext-dnssec-records-10.txt >
	DNS Extensions R. Arends		DNS Extensions R. Arends
	Internet-Draft Telematica Instituut		Internet-Draft Telematica Instituut
	Expires: January 13, 2005 R. Austein		Expires: March 21, 2005 R. Austein
	ISC		ISC
	M. Larson		M. Larson
	VeriSign		VeriSign
	D. Massey		D. Massey
	USC/ISI		USC/ISI
	S. Rose		S. Rose
	NIST		NIST
	July 15, 2004		September 20, 2004
	Resource Records for the DNS Security Extensions		Resource Records for the DNS Security Extensions
	draft-ietf-dnsext-dnssec-records-09		draft-ietf-dnsext-dnssec-records-10
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		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 become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		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 January 13, 2005.		This Internet-Draft will expire on March 21, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This document is part of a family of documents that describes the DNS		This document is part of a family of documents that describes the DNS
	Security Extensions (DNSSEC). The DNS Security Extensions are a		Security Extensions (DNSSEC). The DNS Security Extensions are a
	collection of resource records and protocol modifications that		collection of resource records and protocol modifications that
	provide source authentication for the DNS. This document defines the		provide source authentication for the DNS. This document defines the
	public key (DNSKEY), delegation signer (DS), resource record digital		public key (DNSKEY), delegation signer (DS), resource record digital
	signature (RRSIG), and authenticated denial of existence (NSEC)		signature (RRSIG), and authenticated denial of existence (NSEC)
	resource records. The purpose and format of each resource record is		resource records. The purpose and format of each resource record is
	described in detail, and an example of each resource record is given.		described in detail, and an example of each resource record is given.
	This document obsoletes RFC 2535 and incorporates changes from all		This document obsoletes RFC 2535 and incorporates changes from all
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 14 ¶
	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
	presentation format (ASCII representation).		presentation format (ASCII representation).
	1.1 Background and Related Documents		1.1 Background and Related Documents
	The reader is assumed to be familiar with the basic DNS concepts		This document is part of a family of documents that define DNSSEC,
	described in [RFC1034], [RFC1035] and subsequent RFCs that update		which should be read together as a set.
	them: [RFC2136], [RFC2181] and [RFC2308].
	This document is part of a family of documents that define the DNS		[I-D.ietf-dnsext-dnssec-intro] contains an introduction to DNSSEC and
	security extensions. The DNS security extensions (DNSSEC) are a		definition of common terms; the reader is assumed to be familiar with
	collection of resource records and DNS protocol modifications that		this document. [I-D.ietf-dnsext-dnssec-intro] also contains a list
	add source authentication and data integrity to the Domain Name		of other documents updated by and obsoleted by this document set.
	System (DNS). An introduction to DNSSEC and definitions of common
	terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is		[I-D.ietf-dnsext-dnssec-protocol] defines the DNSSEC protocol
	assumed to be familiar with this document. A description of DNS		operations.
	protocol modifications can be found in
	[I-D.ietf-dnsext-dnssec-protocol].		The reader is also assumed to be familiar with the basic DNS concepts
			described in [RFC1034], [RFC1035], and the subsequent documents that
			update them, particularly [RFC2181] and [RFC2308].
	This document defines the DNSSEC resource records.		This document defines the DNSSEC resource records.
	1.2 Reserved Words		1.2 Reserved Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. The DNSKEY Resource Record		2. The DNSKEY Resource Record
	DNSSEC uses public key cryptography to sign and authenticate DNS		DNSSEC uses public key cryptography to sign and authenticate DNS
	resource record sets (RRsets). The public keys are stored in DNSKEY		resource record sets (RRsets). The public keys are stored in DNSKEY
	resource records and are used in the DNSSEC authentication process		resource records and are used in the DNSSEC authentication process
	described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its		described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
	authoritative RRsets using a private key and stores the corresponding		authoritative RRsets using a private key and stores the corresponding
	public key in a DNSKEY RR. A resolver can then use the public key to		public key in a DNSKEY RR. A resolver can then use the public key to
	authenticate signatures covering the RRsets in the zone.		authenticate signatures covering the RRsets in the zone.
	skipping to change at page 10, line 35 ¶		skipping to change at page 10, line 35 ¶
	[I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original		[I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
	TTL field value to reconstruct the original TTL.		TTL field value to reconstruct the original TTL.
	3.1.5 Signature Expiration and Inception Fields		3.1.5 Signature Expiration and Inception Fields
	The Signature Expiration and Inception fields specify a validity		The Signature Expiration and Inception fields specify a validity
	period for the signature. The RRSIG record MUST NOT be used for		period for the signature. The RRSIG record MUST NOT be used for
	authentication prior to the inception date and MUST NOT be used for		authentication prior to the inception date and MUST NOT be used for
	authentication after the expiration date.		authentication after the expiration date.
	Signature Expiration and Inception field values are in POSIX.1 time		The Signature Expiration and Inception field values specify a date
	format: a 32-bit unsigned number of seconds elapsed since 1 January		and time in the form of a 32-bit unsigned number of seconds elapsed
	1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The		since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
	longest interval which can be expressed by this format without		byte order. The longest interval which can be expressed by this
	wrapping is approximately 136 years. An RRSIG RR can have an		format without wrapping is approximately 136 years. An RRSIG RR can
	Expiration field value which is numerically smaller than the		have an Expiration field value which is numerically smaller than the
	Inception field value if the expiration field value is near the		Inception field value if the expiration field value is near the
	32-bit wrap-around point or if the signature is long lived. Because		32-bit wrap-around point or if the signature is long lived. Because
	of this, all comparisons involving these fields MUST use "Serial		of this, all comparisons involving these fields MUST use "Serial
	number arithmetic" as defined in [RFC1982]. As a direct consequence,		number arithmetic" as defined in [RFC1982]. As a direct consequence,
	the values contained in these fields cannot refer to dates more than		the values contained in these fields cannot refer to dates more than
	68 years in either the past or the future.		68 years in either the past or the future.
	3.1.6 The Key Tag Field		3.1.6 The Key Tag Field
	The Key Tag field contains the key tag value of the DNSKEY RR that		The Key Tag field contains the key tag value of the DNSKEY RR that
	skipping to change at page 23, line 33 ¶		skipping to change at page 23, line 33 ¶
	security protocol described in [RFC2931] and the transaction KEY		security protocol described in [RFC2931] and the transaction KEY
	Resource Record described in [RFC2930].		Resource Record described in [RFC2930].
	DNS Security Algorithm Numbers: [RFC2535] created an IANA registry		DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
	for DNSSEC Resource Record Algorithm field numbers, and assigned		for DNSSEC Resource Record Algorithm field numbers, and assigned
	values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755]		values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755]
	altered this registry to include flags for each entry regarding		altered this registry to include flags for each entry regarding
	its use with the DNS security extensions. Each algorithm entry		its use with the DNS security extensions. Each algorithm entry
	could refer to an algorithm that can be used for zone signing,		could refer to an algorithm that can be used for zone signing,
	transaction security (see [RFC2931]) or both. Values 6-251 are		transaction security (see [RFC2931]) or both. Values 6-251 are
	available for assignment by IETF standards action. See Appendix A		available for assignment by IETF standards action [RFC3755]. See
	for a full listing of the DNS Security Algorithm Numbers entries		Appendix A for a full listing of the DNS Security Algorithm
	at the time of writing and their status of use in DNSSEC.		Numbers entries at the time of writing and their status of use in
			DNSSEC.
	[RFC3658] created an IANA registry for DNSSEC DS Digest Types, and		[RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
	assigned value 0 to reserved and value 1 to SHA-1.		assigned value 0 to reserved and value 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 values other than 3		Protocol Values, but [RFC3445] re-assigned all values other than 3
	to reserved and closed this IANA registry. The registry remains		to reserved and closed this IANA registry. The registry remains
	closed, and all KEY and DNSKEY records are required to have		closed, and all KEY and DNSKEY records are required to have
	Protocol Octet value of 3.		Protocol Octet value of 3.
	Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA		Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
	registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,		registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
	this registry only contains an assignment for bit 7 (the ZONE bit)		this registry only contains an assignment for bit 7 (the ZONE bit)
	and a reservation for bit 15 for the Secure Entry Point flag (SEP		and a reservation for bit 15 for the Secure Entry Point flag (SEP
	bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by		bit) [RFC3757]. As also stated in [RFC3755], bits 0-6 and 8-14
	IETF Standards Action.		are available for assignment by IETF Standards Action.
	8. Security Considerations		8. Security Considerations
	This document describes the format of four DNS resource records used		This document describes the format of four DNS resource records used
	by the DNS security extensions, and presents an algorithm for		by the DNS security extensions, and presents an algorithm for
	calculating a key tag for a public key. Other than the items		calculating a key tag for a public key. Other than the items
	described below, the resource records themselves introduce no		described below, the resource records themselves introduce no
	security considerations. Please see [I-D.ietf-dnsext-dnssec-intro]		security considerations. Please see [I-D.ietf-dnsext-dnssec-intro]
	and [I-D.ietf-dnsext-dnssec-protocol] for additional security		and [I-D.ietf-dnsext-dnssec-protocol] for additional security
	considerations related to the use of these records.		considerations related to the use of these records.
	skipping to change at page 26, line 43 ¶		skipping to change at page 26, line 43 ¶
	[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic		[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
	Updates in the Domain Name System (DNS UPDATE)", RFC 2136,		Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
	April 1997.		April 1997.
	[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS		[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	Specification", RFC 2181, July 1997.		Specification", RFC 2181, July 1997.
	[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS		[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
	NCACHE)", RFC 2308, March 1998.		NCACHE)", RFC 2308, March 1998.
			[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
			(DNS)", RFC 2536, March 1999.
	[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC		[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
	2671, August 1999.		2671, August 1999.
	[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (		[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
	SIG(0)s)", RFC 2931, September 2000.		SIG(0)s)", RFC 2931, September 2000.
	[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain		[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
	Name System (DNS)", RFC 3110, May 2001.		Name System (DNS)", RFC 3110, May 2001.
	[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY		[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
	skipping to change at page 27, line 23 ¶		skipping to change at page 27, line 26 ¶
	(RR)", RFC 3658, December 2003.		(RR)", RFC 3658, December 2003.
	[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation		[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
	Signer", RFC 3755, April 2004.		Signer", RFC 3755, April 2004.
	[RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure		[RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
	Entry Point Flag", RFC 3757, April 2004.		Entry Point Flag", RFC 3757, April 2004.
	10.2 Informative References		10.2 Informative References
	[I-D.ietf-dnsext-nsec-rdata]
	Schlyter, J., "DNSSEC NSEC RDATA Format",
	draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
	2004.
	[RFC2535] Eastlake, D., "Domain Name System Security Extensions",		[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
	RFC 2535, March 1999.		RFC 2535, March 1999.
			[RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
			System (DNS)", RFC 2537, March 1999.
			[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
			Domain Name System (DNS)", RFC 2539, March 1999.
	[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY		[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
	RR)", RFC 2930, September 2000.		RR)", RFC 2930, September 2000.
			[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
			RDATA Format", RFC 3845, August 2004.
	Authors' Addresses		Authors' Addresses
	Roy Arends		Roy Arends
	Telematica Instituut		Telematica Instituut
	Drienerlolaan 5		Drienerlolaan 5
	7522 NB Enschede		7522 NB Enschede
	NL		NL
	EMail: roy.arends@telin.nl		EMail: roy.arends@telin.nl
	Rob Austein		Rob Austein
	skipping to change at page 29, line 36 ¶		skipping to change at page 29, line 36 ¶
	Some algorithms are usable only for zone signing (DNSSEC), some only		Some algorithms are usable only for zone signing (DNSSEC), some only
	for transaction security mechanisms (SIG(0) and TSIG), and some for		for transaction security mechanisms (SIG(0) and TSIG), and some for
	both. Those usable for zone signing may appear in DNSKEY, RRSIG, and		both. Those usable for zone signing may appear in DNSKEY, RRSIG, and
	DS RRs. Those usable for transaction security would be present in		DS RRs. Those usable for transaction security would be present in
	SIG(0) and KEY RRs as described in [RFC2931]		SIG(0) and KEY RRs as described in [RFC2931]
	Zone		Zone
	Value Algorithm [Mnemonic] Signing References Status		Value Algorithm [Mnemonic] Signing References Status
	----- -------------------- --------- ---------- ---------		----- -------------------- --------- ---------- ---------
	0 reserved		0 reserved
	1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED		1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
	2 Diffie-Hellman [DH] n RFC 2539 -		2 Diffie-Hellman [DH] n [RFC2539] -
	3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL		3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
	4 Elliptic Curve [ECC] TBA -		4 Elliptic Curve [ECC] TBA -
	5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY		5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
	252 Indirect [INDIRECT] n -		252 Indirect [INDIRECT] n -
	253 Private [PRIVATEDNS] y see below OPTIONAL		253 Private [PRIVATEDNS] y see below OPTIONAL
	254 Private [PRIVATEOID] y see below OPTIONAL		254 Private [PRIVATEOID] y see below OPTIONAL
	255 reserved		255 reserved
	6 - 251 Available for assignment by IETF Standards Action.		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
	skipping to change at page 31, line 37 ¶		skipping to change at page 31, line 37 ¶
	these groups are then added together ignoring any carry bits.		these groups are then added together ignoring any carry bits.
	A reference implementation of the key tag algorithm is as an ANSI C		A reference implementation of the key tag algorithm is as an ANSI C
	function is given below with the RDATA portion of the DNSKEY RR is		function is given below with the RDATA portion of the DNSKEY RR is
	used as input. It is not necessary to use the following reference		used as input. It is not necessary to use the following reference
	code verbatim, but the numerical value of the Key Tag MUST be		code verbatim, but the numerical value of the Key Tag MUST be
	identical to what the reference implementation would generate for the		identical to what the reference implementation would generate for the
	same input.		same input.
	Please note that the algorithm for calculating the Key Tag is almost		Please note that the algorithm for calculating the Key Tag is almost
	but not completely identical to the familiar ones complement checksum		but not completely identical to the familiar ones-complement checksum
	used in many other Internet protocols. Key Tags MUST be calculated		used in many other Internet protocols. Key Tags MUST be calculated
	using the algorithm described here rather than the ones complement		using the algorithm described here rather than the ones complement
	checksum.		checksum.
	The following ANSI C reference implementation calculates the value of		The following ANSI C reference implementation calculates the value of
	a Key Tag. This reference implementation applies to all algorithm		a Key Tag. This reference implementation applies to all algorithm
	types except algorithm 1 (see Appendix B.1). The input is the wire		types except algorithm 1 (see Appendix B.1). The input is the wire
	format of the RDATA portion of the DNSKEY RR. The code is written		format of the RDATA portion of the DNSKEY RR. The code is written
	for clarity, not efficiency.		for clarity, not efficiency.
End of changes. 20 change blocks.
	43 lines changed or deleted		53 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/