< draft-ietf-regext-dnsoperator-to-rrr-protocol-02.txt		draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt >
	regext J. Latour		regext J. Latour
	Internet-Draft CIRA		Internet-Draft CIRA
	Intended status: Standards Track O. Gudmundsson		Intended status: Standards Track O. Gudmundsson
	Expires: July 14, 2017 Cloudflare, Inc.		Expires: September 13, 2017 Cloudflare, Inc.
	P. Wouters		P. Wouters
	Red Hat		Red Hat
	M. Pounsett		M. Pounsett
	Rightside Group, Ltd.		Rightside Group, Ltd.
	January 10, 2017		March 12, 2017
	Third Party DNS operator to Registrars/Registries Protocol		Third Party DNS operator to Registrars/Registries Protocol
	draft-ietf-regext-dnsoperator-to-rrr-protocol-02.txt		draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt
	Abstract		Abstract
	There are several problems that arise in the standard		There are several problems that arise in the standard
	Registrant/Registrar/Registry model when the operator of a zone is		Registrant/Registrar/Registry model when the operator of a zone is
	neither the Registrant nor the Registrar for the delegation.		neither the Registrant nor the Registrar for the delegation.
	Historically the issues have been minor, and limited to difficulty		Historically the issues have been minor, and limited to difficulty
	guiding the Registrant through the initial changes to the NS records		guiding the Registrant through the initial changes to the NS records
	for the delegation. As this is usually a one time activity when the		for the delegation. As this is usually a one time activity when the
	operator first takes charge of the zone it has not been treated as a		operator first takes charge of the zone it has not been treated as a
	serious issue.		serious issue.
	When the domain hand uses DNSSEC it necessary to make regular		When the domain uses DNSSEC it necessary to make regular (sometimes
	(sometimes annual) changes to the delegation, updating DS record(s)		annual) changes to the delegation, updating DS record(s) in order to
	in order to track KSK rollover. Under the current model this is		track KSK rollover. Under the current model this is prone to delays
	prone to delays and errors, as the Registrant must participate in		and errors, as the Registrant must participate in updates to DS
	updates to DS records.		records.
	This document describes a simple protocol that allows a third party		This document describes a simple protocol that allows a third party
	DNS operator to update DS and NS records for a delegation, in a		DNS operator to update DS records for a delegation, in a trusted
	trusted manner, without involving the Registrant for each operation.		manner, without involving the Registrant for each operation. This
	This same protocol can be used by Registrants.		same protocol can be used by Registrants.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 July 14, 2017.		This Internet-Draft will expire on September 13, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 43 ¶		skipping to change at page 2, line 43 ¶
	3.3. Maintaining the Chain of Trust . . . . . . . . . . . . . 5		3.3. Maintaining the Chain of Trust . . . . . . . . . . . . . 5
	3.4. Other Delegation Maintenance . . . . . . . . . . . . . . 5		3.4. Other Delegation Maintenance . . . . . . . . . . . . . . 5
	3.5. Acceptance Processing . . . . . . . . . . . . . . . . . . 5		3.5. Acceptance Processing . . . . . . . . . . . . . . . . . . 5
	4. API Definition . . . . . . . . . . . . . . . . . . . . . . . 6		4. API Definition . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7		4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7
	4.2. RESTful Resources . . . . . . . . . . . . . . . . . . . . 7		4.2. RESTful Resources . . . . . . . . . . . . . . . . . . . . 7
	4.2.1. CDS resource . . . . . . . . . . . . . . . . . . . . 7		4.2.1. CDS resource . . . . . . . . . . . . . . . . . . . . 7
	4.2.2. Token resource . . . . . . . . . . . . . . . . . . . 9		4.2.2. Token resource . . . . . . . . . . . . . . . . . . . 9
	4.3. Customized Error Messages . . . . . . . . . . . . . . . . 10		4.3. Customized Error Messages . . . . . . . . . . . . . . . . 10
	5. Security considerations . . . . . . . . . . . . . . . . . . . 10		5. Security considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Internationalization Considerations . . . . . . . . . . . . . 11		7. Internationalization Considerations . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Document History . . . . . . . . . . . . . . . . . . 12		Appendix A. Document History . . . . . . . . . . . . . . . . . . 12
	A.1. regext Version 02 . . . . . . . . . . . . . . . . . . . . 12		A.1. regext Version 03 . . . . . . . . . . . . . . . . . . . . 12
	A.2. regext Version 02 not pushed . . . . . . . . . . . . . . 12		A.2. regext Version 02 . . . . . . . . . . . . . . . . . . . . 13
	A.3. regext Version 01 . . . . . . . . . . . . . . . . . . . . 12		A.3. regext Version 01 . . . . . . . . . . . . . . . . . . . . 13
	A.4. regext Version 00 . . . . . . . . . . . . . . . . . . . . 13		A.4. regext Version 00 . . . . . . . . . . . . . . . . . . . . 13
	A.5. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 13		A.5. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 13
	A.6. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 13		A.6. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 13
	A.7. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 13		A.7. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 13
	A.8. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 13		A.8. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	After a domain has been registered, one of three parties will		After a domain has been registered, one of three parties will
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 48 ¶
	model. The failures result in either the inability to use DNSSEC or		model. The failures result in either the inability to use DNSSEC or
	in validation failures that cause the domain to become unavailable to		in validation failures that cause the domain to become unavailable to
	users behind validating resolvers.		users behind validating resolvers.
	The goal of this document is to create a protocol for establishing a		The goal of this document is to create a protocol for establishing a
	secure chain of trust that involves parties not in the traditional		secure chain of trust that involves parties not in the traditional
	Registrant/Registrar/Registry (RRR) model, and to reduce the friction		Registrant/Registrar/Registry (RRR) model, and to reduce the friction
	in maintaining DNSSEC secured delegations in these cases. It		in maintaining DNSSEC secured delegations in these cases. It
	describes a REST-based [RFC6690] protocol which can be used to		describes a REST-based [RFC6690] protocol which can be used to
	establish DNSSEC initial trust (to enable or bootstrap DNSSEC), and		establish DNSSEC initial trust (to enable or bootstrap DNSSEC), and
	to trigger maintenance of delegation records such as DS, NS, and glue		to trigger maintenance of DS records.
	records.
	2. Notional Conventions		2. Notional Conventions
	2.1. Definitions		2.1. Definitions
	For the purposes of this draft, a third-party DNS Operator is any DNS		For the purposes of this draft, a third-party DNS Operator is any DNS
	Operator responsible for a zone, where the operator is neither the		Operator responsible for a zone, where the operator is neither the
	Registrant nor the Registrar of record for the delegation.		Registrant nor the Registrar of record for the delegation.
	Uses of "child" and "parent" refer to the relationship between DNS		Uses of "child" and "parent" refer to the relationship between DNS
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 13 ¶
	the base URL of the API is considered out of scope of this document.		the base URL of the API is considered out of scope of this document.
	The authors recommend standardization of an RDAP extension to obtain		The authors recommend standardization of an RDAP extension to obtain
	this information from the Registry.		this information from the Registry.
	3.2. Establishing a Chain of Trust		3.2. Establishing a Chain of Trust
	After signing the zone, the child operator needs to upload the DS		After signing the zone, the child operator needs to upload the DS
	record(s) to the parent. The child can signal its desire to have		record(s) to the parent. The child can signal its desire to have
	DNSSEC validation enabled by publishing one of the special DNS		DNSSEC validation enabled by publishing one of the special DNS
	records CDS and/or CDNSKEY as defined in [RFC7344] and		records CDS and/or CDNSKEY as defined in [RFC7344] and [RFC8078].
	[I-D.ietf-dnsop-maintain-ds].
	[RFC Editor: The above I-D reference should be replaced with the		[RFC Editor: The above I-D reference should be replaced with the
	correct RFC number upon publication.]		correct RFC number upon publication.]
	In the case of an insecure delegation, the Registrar will normally		In the case of an insecure delegation, the Registrar will normally
	not be scanning the child zone for CDS/CDNSKEY records. The child		not be scanning the child zone for CDS/CDNSKEY records. The child
	operator can use this protocol to notify the Registrar to begin such		operator can use this protocol to notify the Registrar to begin such
	a scan.		a scan.
	Once the Registrar sees these records it SHOULD start acceptance		Once the Registrar sees these records it SHOULD start acceptance
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 46 ¶
	4.2.1.1.1. Request		4.2.1.1.1. Request
	Syntax: POST /domains/{domain}/cds		Syntax: POST /domains/{domain}/cds
	Request that an initial set of DS records based on the CDS record in		Request that an initial set of DS records based on the CDS record in
	the child zone be inserted into the Registry and the parent zone upon		the child zone be inserted into the Registry and the parent zone upon
	the successful completion of the request. If there are multiple CDS		the successful completion of the request. If there are multiple CDS
	records in the CDS RRset, multiple DS records will be added.		records in the CDS RRset, multiple DS records will be added.
			The body of the POST SHOULD be empty, however server implementations
			SHOULD NOT reject nonempty requests.
	4.2.1.1.2. Response		4.2.1.1.2. Response
	o HTTP Status code 201 indicates a success.		o HTTP Status code 201 indicates a success.
	o HTTP Status code 400 indicates a failure due to validation.		o HTTP Status code 400 indicates a failure due to validation.
	o HTTP Status code 401 indicates an unauthorized resource access.		o HTTP Status code 401 indicates an unauthorized resource access.
	o HTTP Status code 403 indicates a failure due to an invalid		o HTTP Status code 403 indicates a failure due to an invalid
	challenge token.		challenge token.
	skipping to change at page 9, line 41 ¶		skipping to change at page 9, line 48 ¶
	reasons.		reasons.
	4.2.2. Token resource		4.2.2. Token resource
	Path: /domains/{domain}/token		Path: /domains/{domain}/token
	4.2.2.1. Establish Initial Trust with Challenge		4.2.2.1. Establish Initial Trust with Challenge
	4.2.2.1.1. Request		4.2.2.1.1. Request
	Syntax: POST /domains/{domain}/token		Syntax: GET /domains/{domain}/token
	The DNSSEC policy of the Registrar may require proof that the DNS		The DNSSEC policy of the Registrar may require proof that the DNS
	Operator is in control of the domain. The token API call returns a		Operator is in control of the domain. The token API call returns a
	random token to be included as a TXT record for the _delegate.@		random token to be included as a TXT record for the _delegate.@
	domain name (where @ is the apex of the child zone) prior		domain name (where @ is the apex of the child zone) prior
	establishing the DNSSEC initial trust. This is an additional trust		establishing the DNSSEC initial trust. This is an additional trust
	control mechanism to establish the initial chain of trust.		control mechanism to establish the initial chain of trust.
	Once the child operator has received a token, it SHOULD be inserted		Once the child operator has received a token, it SHOULD be inserted
	in the zone and the operator SHOULD proceed with a POST of the cds		in the zone and the operator SHOULD proceed with a POST of the cds
	resource.		resource.
			The Registrar MAY expire the token after a reasonable period. The
			Registrar SHOULD document an explanation of whether and when tokens
			are expired in their DNSSEC policy.
	Note that the _delegate TXT record is publicly available and not a		Note that the _delegate TXT record is publicly available and not a
	secret token.		secret token.
	4.2.2.1.2. Response		4.2.2.1.2. Response
	o HTTP Status code 200 indicates a success. A token is included in		o HTTP Status code 200 indicates a success. A token is included in
	the body of the response, as a valid TXT record		the body of the response, as a valid TXT record
	o HTTP Status code 404 indicates the domain does not exist.		o HTTP Status code 404 indicates the domain does not exist.
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 27 ¶
	7. Internationalization Considerations		7. Internationalization Considerations
	This protocol is designed for machine to machine communications.		This protocol is designed for machine to machine communications.
	Clients and servers should use punycode [RFC3492] when operating on		Clients and servers should use punycode [RFC3492] when operating on
	internationalized domain names.		internationalized domain names.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-dnsop-maintain-ds]
	Gudmundsson, O. and P. Wouters, "Managing DS records from
	parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-04
	(work in progress), October 2016.
	[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode		[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
	for Internationalized Domain Names in Applications		for Internationalized Domain Names in Applications
	(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,		(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
	<http://www.rfc-editor.org/info/rfc3492>.		<http://www.rfc-editor.org/info/rfc3492>.
	[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link		[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
	Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,		Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
	<http://www.rfc-editor.org/info/rfc6690>.		<http://www.rfc-editor.org/info/rfc6690>.
	[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating		[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
	DNSSEC Delegation Trust Maintenance", RFC 7344, DOI		DNSSEC Delegation Trust Maintenance", RFC 7344, DOI
	10.17487/RFC7344, September 2014,		10.17487/RFC7344, September 2014,
	<http://www.rfc-editor.org/info/rfc7344>.		<http://www.rfc-editor.org/info/rfc7344>.
			[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
			the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/
			RFC8078, March 2017,
			<http://www.rfc-editor.org/info/rfc8078>.
	8.2. Informative References		8.2. Informative References
	[I-D.wallstrom-dnsop-dns-delegation-requirements]		[I-D.wallstrom-dnsop-dns-delegation-requirements]
	Wallstrom, P. and J. Schlyter, "DNS Delegation		Wallstrom, P. and J. Schlyter, "DNS Delegation
	Requirements", draft-wallstrom-dnsop-dns-delegation-		Requirements", draft-wallstrom-dnsop-dns-delegation-
	requirements-03 (work in progress), October 2016.		requirements-03 (work in progress), October 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	RFC2119, March 1997,		RFC2119, March 1997,
	skipping to change at page 12, line 17 ¶		skipping to change at page 12, line 30 ¶
	Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,		Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
	<http://www.rfc-editor.org/info/rfc6841>.		<http://www.rfc-editor.org/info/rfc6841>.
	[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the		[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
	Registration Data Access Protocol (RDAP)", RFC 7480, DOI		Registration Data Access Protocol (RDAP)", RFC 7480, DOI
	10.17487/RFC7480, March 2015,		10.17487/RFC7480, March 2015,
	<http://www.rfc-editor.org/info/rfc7480>.		<http://www.rfc-editor.org/info/rfc7480>.
	Appendix A. Document History		Appendix A. Document History
	A.1. regext Version 02		A.1. regext Version 03
	o simplify abstract		o simplify abstract
	o move all justification text to Intro		o move all justification text to Intro
	o added HTTP response codes for rate limiting (429), missing DS		o added HTTP response codes for rate limiting (429), missing DS
	RRsets (412)		RRsets (412)
	o expanded on Internationalization Considerations		o expanded on Internationalization Considerations
	o corrected informative/normative document references		o corrected informative/normative document references
	o clarify parent/Registrar references in the draft		o clarify parent/Registrar references in the draft
	o general spelling/grammar/style cleanup		o general spelling/grammar/style cleanup
	A.2. regext Version 02 not pushed		o removed references to NS and glue maintenance
			o clarify content of POST body for 'cds' resource
			o change verb for obtaining a 'token' to GET
			o Updated refernce to RFC8078
			A.2. regext Version 02
	o Clarified based on comments and questions from early implementors		o Clarified based on comments and questions from early implementors
	(JL)		(JL)
	o Text edits and clarifications.		o Text edits and clarifications.
	A.3. regext Version 01		A.3. regext Version 01
	o Rewrote Abstract and Into (MP)		o Rewrote Abstract and Into (MP)
	skipping to change at page 13, line 30 ¶		skipping to change at page 13, line 46 ¶
	suggestions from Jakob Schlyter.		suggestions from Jakob Schlyter.
	A.8. Version 00		A.8. Version 00
	o First rough version		o First rough version
	Authors' Addresses		Authors' Addresses
	Jacques Latour		Jacques Latour
	CIRA		CIRA
			Ottawa, ON
	Email: jacques.latour@cira.ca		Email: jacques.latour@cira.ca
	Olafur Gudmundsson		Olafur Gudmundsson
	Cloudflare, Inc.		Cloudflare, Inc.
			San Francisco, CA
	Email: olafur+ietf@cloudflare.com		Email: olafur+ietf@cloudflare.com
	Paul Wouters		Paul Wouters
	Red Hat		Red Hat
			Toronto, ON
	Email: paul@nohats.ca		Email: paul@nohats.ca
	Matthew Pounsett		Matthew Pounsett
	Rightside Group, Ltd.		Rightside Group, Ltd.
			Toronto, ON
	Email: matt@conundrum.com		Email: matt@conundrum.com
End of changes. 22 change blocks.
	29 lines changed or deleted		44 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/