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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/