< draft-ietf-dnsop-delegation-trust-maintainance-12.txt		draft-ietf-dnsop-delegation-trust-maintainance-13.txt >
	dnsop W. Kumari		dnsop W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Intended status: Informational O. Gudmundsson		Intended status: Informational O. Gudmundsson
	Expires: October 30, 2014 Shinkuro Inc.		Expires: November 04, 2014 Shinkuro Inc.
	G. Barwood		G. Barwood
	April 28, 2014		May 03, 2014
	Automating DNSSEC Delegation Trust Maintenance		Automating DNSSEC Delegation Trust Maintenance
	draft-ietf-dnsop-delegation-trust-maintainance-12		draft-ietf-dnsop-delegation-trust-maintainance-13
	Abstract		Abstract
	This document describes a method to allow DNS operators to more		This document describes a method to allow DNS operators to more
	easily update DNSSEC Key Signing Keys using the DNS as communication		easily update DNSSEC Key Signing Keys using the DNS as communication
	channel. The technique described is aimed at delegations in which it		channel. The technique described is aimed at delegations in which it
	is currently hard to move information from the child to parent.		is currently hard to move information from the child to parent.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on October 30, 2014.		This Internet-Draft will expire on November 04, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4		1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. DNS Delegations . . . . . . . . . . . . . . . . . . . . . 4		2.1. DNS Delegations . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Relationship Between Parent and Child DNS Operator . . . 5		2.2. Relationship Between Parent and Child DNS Operator . . . 5
	2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6		2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6
	2.2.2. DNSSEC key change process . . . . . . . . . . . . . . 7		2.2.2. DNSSEC key change process . . . . . . . . . . . . . . 6
	3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions . 7		3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions . 7
	3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 8		3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 7
	3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8		3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8
	4. Automating DS Maintenance With CDS / CDNSKEY records . . . . 8		4. Automating DS Maintenance With CDS / CDNSKEY records . . . . 8
	4.1. CDS / CDNSKEY Processing Rules . . . . . . . . . . . . . 8		4.1. CDS / CDNSKEY Processing Rules . . . . . . . . . . . . . 8
	5. CDS / CDNSKEY Publication . . . . . . . . . . . . . . . . . . 9		5. CDS / CDNSKEY Publication . . . . . . . . . . . . . . . . . . 9
	6. Parent Side CDS / CDNSKEY Consumption . . . . . . . . . . . . 9		6. Parent Side CDS / CDNSKEY Consumption . . . . . . . . . . . . 9
	6.1. Detecting a Changed CDS / CDNSKEY . . . . . . . . . . . . 9		6.1. Detecting a Changed CDS / CDNSKEY . . . . . . . . . . . . 9
	6.1.1. CDS / CDNSKEY Polling . . . . . . . . . . . . . . . . 10		6.1.1. CDS / CDNSKEY Polling . . . . . . . . . . . . . . . . 10
	6.1.2. Polling Triggers . . . . . . . . . . . . . . . . . . 10		6.1.2. Polling Triggers . . . . . . . . . . . . . . . . . . 10
	6.2. Using the New CDS / CDNSKEY Records . . . . . . . . . . . 11		6.2. Using the New CDS / CDNSKEY Records . . . . . . . . . . . 11
	6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11		6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 14		11.1. Normative References . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . 15		11.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15		Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15
	Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16		Appendix B. CDS key rollover example . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Appendix C. Changes / Author Notes. . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	The first time a DNS operator signs a zone, they need to communicate		The first time a DNS operator signs a zone, they need to communicate
	the keying material to their parent through some out-of-band method		the keying material to their parent through some out-of-band method
	to complete the chain of trust. Depending on the desires of the		to complete the chain of trust. Depending on the desires of the
	parent, the child might send their DNSKEY record, a DS record, or		parent, the child might send their DNSKEY record, a DS record, or
	both.		both.
	Each time the child changes the key that is represented in the		Each time the child changes the key that is represented in the
	skipping to change at page 16, line 19 ¶		skipping to change at page 16, line 16 ¶
	the Registrar; frequently the Registry is not allowed to communicate		the Registrar; frequently the Registry is not allowed to communicate
	with the Registrant. In that case as far as the registrant is		with the Registrant. In that case as far as the registrant is
	concerned the Registrar is the same entity as the Parent.		concerned the Registrar is the same entity as the Parent.
	In many RRR cases the Registrar and Registry communicate via		In many RRR cases the Registrar and Registry communicate via
	EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number		EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number
	of ccTLDs there are other mechanisms in use as well as EPP, but in		of ccTLDs there are other mechanisms in use as well as EPP, but in
	general there seems to be a movement towards EPP usage when DNSSEC is		general there seems to be a movement towards EPP usage when DNSSEC is
	enabled in the TLD.		enabled in the TLD.
	Appendix B. Changes / Author Notes.		Appendix B. CDS key rollover example
			This section shows an example on how CDS is used when performing a
			KSK rollover, this example will demonstrate the the double DS
			rollover method from section 4.1.2 in [RFC6781]. Other rollovers
			using CDNSKEY and double KSK are left as an exersize to the reader.
			The table below does not reflect the ZSK keys as they are not
			material during KSK rollovers. The wait states below are highlight
			what RRset needs to expire from caches before progressign to the next
			step.
			+-------+---------------+----------+---------+------------+---------+
			| Step | State | Parent | Child | DNSKEY and | Child |
			| | | DS | KSK | CDS signer | CDS |
			+-------+---------------+----------+---------+------------+---------+
			| 0 | Beginning | A | A | A | |
			| 1 | Add CDS | A | A | A | AB |
			| 2 | Wait for DS | A | A | A | AB |
			| | change | | | | |
			| 3 | Updated DS | AB | A | A | AB |
			| 4 | wait > DS TTL | AB | A | A | AB |
			| 5 | Actual | AB | B | B | AB |
			| | Rollover | | | | |
			| 6 | wait > DNSKEY | AB | B | B | AB |
			| | TTL | | | | |
			| 7 | Cleanup | AB | B | B | B |
			| | starts | | | | |
			| 8 | Parent | B | B | B | B |
			| | updates | | | | |
			| 9 | Optional CDS | B | B | B | |
			| | delete | | | | |
			+-------+---------------+----------+---------+------------+---------+
			Table 1: States
			End text
			Appendix C. Changes / Author Notes.
	[RFC Editor: Please remove this section before publication ]		[RFC Editor: Please remove this section before publication ]
			WG-12 to WG-13
			o Added appendix B showing Key rollover using CDS.
	WG-11 to WG-12		WG-11 to WG-12
	o Many nits and helpful grammar fixes from Jeremy C. Reed.		o Many nits and helpful grammar fixes from Jeremy C. Reed.
	WG-10 to WG-11		WG-10 to WG-11
	o More useful text from Matthijs.		o More useful text from Matthijs.
	o Explained why the child might want to remove the CDS / CDNSKEY		o Explained why the child might want to remove the CDS / CDNSKEY
	Records.		Records.
End of changes. 10 change blocks.
	10 lines changed or deleted		52 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/