draft-ietf-dnsop-child-syncronization-01.txt		draft-ietf-dnsop-child-syncronization-02.txt
	DNSOP W. Hardaker		DNSOP W. Hardaker
	Internet-Draft Parsons, Inc.		Internet-Draft Parsons, Inc.
	Intended status: Standards Track May 13, 2014		Intended status: Standards Track July 3, 2014
	Expires: November 14, 2014		Expires: January 4, 2015
	Child To Parent Synchronization in DNS		Child To Parent Synchronization in DNS
	draft-ietf-dnsop-child-syncronization-01		draft-ietf-dnsop-child-syncronization-02
	Abstract		Abstract
	This document specifies how a child zone in the DNS can publish a		This document specifies how a child zone in the DNS can publish a
	record to indicate to a parental agent that it may copy and process		record to indicate to a parental agent that it may copy and process
	certain records from the child zone. The existence of and value		certain records from the child zone. The existence of and value
	change of the record may be monitored by a parental agent and acted		change of the record may be monitored by a parental agent and acted
	on as appropriate.		on as appropriate.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 November 14, 2014.		This Internet-Draft will expire on January 4, 2015.
	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 26		skipping to change at page 2, line 26
	3.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . . . 8		3.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . . . 8
	3.2.1. The NS type . . . . . . . . . . . . . . . . . . . . . 8		3.2.1. The NS type . . . . . . . . . . . . . . . . . . . . . 8
	3.2.2. The A and AAAA types . . . . . . . . . . . . . . . . . 8		3.2.2. The A and AAAA types . . . . . . . . . . . . . . . . . 8
	4. Operational Considerations . . . . . . . . . . . . . . . . . . 9		4. Operational Considerations . . . . . . . . . . . . . . . . . . 9
	4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 9		4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 9		4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 9
	4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 10		4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 10
	4.4. Documented Parental Agent Type Support . . . . . . . . . . 10		4.4. Documented Parental Agent Type Support . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	This document specifies how a child zone in the DNS ([RFC1034],		This document specifies how a child zone in the DNS ([RFC1034],
	[RFC1035]) can publish a record to indicate to a parental agent that		[RFC1035]) can publish a record to indicate to a parental agent that
	it may copy and process certain records from the child zone. The		it may copy and process certain records from the child zone. The
	existence of and value change of the record may be monitored by a		existence of and value change of the record may be monitored by a
	parental agent and acted on as appropriate.		parental agent and acted on as appropriate.
	Some resource records (RRs) in a parent zone are typically expected		Currently today, some resource records (RRs) in a parent zone are
	to be in-sync with the source data in the child's zone. The most		typically expected to be in-sync with the source data in the child's
	common records that should match, to date, are the nameserver (NS)		zone. The most common records that should match are the nameserver
	records and any necessary associated address records (A and AAAA),		(NS) records and any necessary associated address records (A and
	also known as "glue records". These records are referred to as		AAAA), also known as "glue records". These records are referred to
	"delegation records".		as "delegation records".
	It has been traditionally challenging for child DNS operators to		It has been traditionally challenging for child DNS operators to
	update their delegation records within the parent's set in a timely		update their delegation records within the parent's set in a timely
	fashion. This difficulty is frequently from simple operator laziness		fashion. This difficulty is frequently from simple operator laziness
	or because of the complexities of maintaining a large number of DNS		or because of the complexities of maintaining a large number of DNS
	zones. Having an automated mechanism for signaling updates will		zones. Having an automated mechanism for signaling updates will
	greatly ease the child zone operator's maintenance burden and improve		greatly ease the child zone operator's maintenance burden and improve
	the robustness of the DNS as a whole.		the robustness of the DNS as a whole.
	This draft introduces a new Resource Record Type (RRType) named		This draft introduces a new Resource Record Type (RRType) named
	skipping to change at page 11, line 26		skipping to change at page 11, line 26
	This specification does not address how to perform bootstrapping		This specification does not address how to perform bootstrapping
	operations to get the required initial DNSSEC-secured operating		operations to get the required initial DNSSEC-secured operating
	environment in place. Additionally, this specification was not		environment in place. Additionally, this specification was not
	designed to synchronize DNSSEC security records, such as DS pointers.		designed to synchronize DNSSEC security records, such as DS pointers.
	For such a solution, please see the complimentary solution		For such a solution, please see the complimentary solution
	[I-D.ietf-dnsop-delegation-trust-maintainance] for maintaining		[I-D.ietf-dnsop-delegation-trust-maintainance] for maintaining
	security delegation information.		security delegation information.
	6. IANA Considerations		6. IANA Considerations
	This document defines a set of single-bit "Flags" for use in the		This document defines a new DNS Resource Record Type, named "CSYNC".
			The IANA is requested to assign a code point from the "Resource
			Record (RR) TYPEs" sub-registry of the "Domain Name System (DNS)
			Parameters" registry
			(http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml)
			for this record.
			TYPE Value Meaning Reference
			----- ------ -------------------------- -----------
			CSYNC TBA Child To Parent Synchronization [This document]
			[ To be removed prior to publication: The CDS (59), CDNSKEY (60) and
			the CSYNC records are all conceptually similar - if the code-point 61
			happens to still be Unassigned when the IANA processes this, it would
			be nice if that could be used for this.]
			The IANA is also requested to create and maintain a sub-registry (the
			"Child Synchronization (CSYNC) Flags" registry) of the "Domain Name
			System (DNS) Parameters" registry. The initial values for this
			registry are below. Assignment of new flag values are subject to
			"RFC Required" specifications [RFC5226].
			This registry will hold a set of single-bit "Flags" for use in the
	CSYNC record within the 16 bit Flags field. Thus, a maximum of 16		CSYNC record within the 16 bit Flags field. Thus, a maximum of 16
	flags may be defined. The two initial flags defined by this document		flags may be defined.
	are:
	0x00 0x01: "immediate"		The initial assignments in this registry are:
	0x00 0x02: "soaminimum"		Bit Flag Description Reference
			---- ------ ------------- -----------
			Bit 0 immediate Immediately process this [This document,
			CSYNC record. Section 3]
	Assignment of new flag values are subject to "RFC Required"		Bit 1 soaminimum Require a SOA serial [This document,
	specifications [RFC5226].		number greater than the Section 2.1.1.1]
			one specified.
	7. Acknowledgments		7. Acknowledgments
	A thank you goes out to Warren Kumari and Olafur Gu[eth]mundsson,		A thank you goes out to Warren Kumari and Olafur Gu[eth]mundsson,
	who's work on the CDS record type helped inspire the work in this		who's work on the CDS record type helped inspire the work in this
	document, as well as the definition for the "parental agent"		document, as well as the definition for the "parental agent"
	definition. A thank you also goes out to Ed Lewis, who the author		definition and significant contributions to the text. A thank you
	held many conversations with about the issues surrounding parent/		also goes out to Ed Lewis, who the author held many conversations
	child relationships and synchronization. Much of the work in this		with about the issues surrounding parent/child relationships and
	document is derived from the careful existing analysis of these three		synchronization. Much of the work in this document is derived from
	esteemed colleagues. Thank you to the following people who have		the careful existing analysis of these three esteemed colleagues.
	contributed text to the document: Matthijs Mekking and Petr Spacek.		Thank you to the following people who have contributed text to the
			document: Matthijs Mekking and Petr Spacek.
	A special thanks goes to Roy Arends, for taking the "bite out of that		A special thanks goes to Roy Arends, for taking the "bite out of that
	hamburger" challenge while discussing this document.		hamburger" challenge while discussing this document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
	August 1996.		August 1996.
	skipping to change at page 12, line 48		skipping to change at page 13, line 28
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, March 2005.		Extensions", RFC 4035, March 2005.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[I-D.ietf-dnsop-delegation-trust-maintainance]		[I-D.ietf-dnsop-delegation-trust-maintainance]
	Kumari, W., Gudmundsson, O., and G. Barwood, "Automating		Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
	DNSSEC Delegation Trust Maintenance",		DNSSEC Delegation Trust Maintenance",
	draft-ietf-dnsop-delegation-trust-maintainance-13 (work in		draft-ietf-dnsop-delegation-trust-maintainance-14 (work in
	progress), May 2014.		progress), June 2014.
	Author's Address		Author's Address
	Wes Hardaker		Wes Hardaker
	Parsons, Inc.		Parsons, Inc.
	P.O. Box 382		P.O. Box 382
	Davis, CA 95617		Davis, CA 95617
	US		US
	Phone: +1 530 792 1913		Phone: +1 530 792 1913
End of changes. 13 change blocks.
	27 lines changed or deleted		53 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/