--- 1/draft-ietf-regext-dnsoperator-to-rrr-protocol-02.txt 2017-03-12 09:13:33.648692161 -0700 +++ 2/draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt 2017-03-12 09:13:33.680692915 -0700 @@ -1,62 +1,62 @@ regext J. Latour Internet-Draft CIRA Intended status: Standards Track O. Gudmundsson -Expires: July 14, 2017 Cloudflare, Inc. +Expires: September 13, 2017 Cloudflare, Inc. P. Wouters Red Hat M. Pounsett Rightside Group, Ltd. - January 10, 2017 + March 12, 2017 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 There are several problems that arise in the standard Registrant/Registrar/Registry model when the operator of a zone is neither the Registrant nor the Registrar for the delegation. Historically the issues have been minor, and limited to difficulty guiding the Registrant through the initial changes to the NS records 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 serious issue. - When the domain hand uses DNSSEC it necessary to make regular - (sometimes annual) changes to the delegation, updating DS record(s) - in order to track KSK rollover. Under the current model this is - prone to delays and errors, as the Registrant must participate in - updates to DS records. + When the domain uses DNSSEC it necessary to make regular (sometimes + annual) changes to the delegation, updating DS record(s) in order to + track KSK rollover. Under the current model this is prone to delays + and errors, as the Registrant must participate in updates to DS + records. This document describes a simple protocol that allows a third party - DNS operator to update DS and NS records for a delegation, in a - trusted manner, without involving the Registrant for each operation. - This same protocol can be used by Registrants. + DNS operator to update DS records for a delegation, in a trusted + manner, without involving the Registrant for each operation. This + same protocol can be used by Registrants. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -78,29 +78,29 @@ 3.3. Maintaining the Chain of Trust . . . . . . . . . . . . . 5 3.4. Other Delegation Maintenance . . . . . . . . . . . . . . 5 3.5. Acceptance Processing . . . . . . . . . . . . . . . . . . 5 4. API Definition . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7 4.2. RESTful Resources . . . . . . . . . . . . . . . . . . . . 7 4.2.1. CDS resource . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Token resource . . . . . . . . . . . . . . . . . . . 9 4.3. Customized Error Messages . . . . . . . . . . . . . . . . 10 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 - 6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Internationalization Considerations . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Document History . . . . . . . . . . . . . . . . . . 12 - A.1. regext Version 02 . . . . . . . . . . . . . . . . . . . . 12 - A.2. regext Version 02 not pushed . . . . . . . . . . . . . . 12 - A.3. regext Version 01 . . . . . . . . . . . . . . . . . . . . 12 + A.1. regext Version 03 . . . . . . . . . . . . . . . . . . . . 12 + A.2. regext Version 02 . . . . . . . . . . . . . . . . . . . . 13 + A.3. regext Version 01 . . . . . . . . . . . . . . . . . . . . 13 A.4. regext Version 00 . . . . . . . . . . . . . . . . . . . . 13 A.5. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 13 A.6. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 13 A.7. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 13 A.8. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction After a domain has been registered, one of three parties will @@ -131,22 +131,21 @@ model. The failures result in either the inability to use DNSSEC or in validation failures that cause the domain to become unavailable to users behind validating resolvers. The goal of this document is to create a protocol for establishing a secure chain of trust that involves parties not in the traditional Registrant/Registrar/Registry (RRR) model, and to reduce the friction in maintaining DNSSEC secured delegations in these cases. It describes a REST-based [RFC6690] protocol which can be used to establish DNSSEC initial trust (to enable or bootstrap DNSSEC), and - to trigger maintenance of delegation records such as DS, NS, and glue - records. + to trigger maintenance of DS records. 2. Notional Conventions 2.1. Definitions 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 Registrant nor the Registrar of record for the delegation. Uses of "child" and "parent" refer to the relationship between DNS @@ -191,22 +190,21 @@ the base URL of the API is considered out of scope of this document. The authors recommend standardization of an RDAP extension to obtain this information from the Registry. 3.2. Establishing a Chain of Trust 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 DNSSEC validation enabled by publishing one of the special DNS - records CDS and/or CDNSKEY as defined in [RFC7344] and - [I-D.ietf-dnsop-maintain-ds]. + records CDS and/or CDNSKEY as defined in [RFC7344] and [RFC8078]. [RFC Editor: The above I-D reference should be replaced with the correct RFC number upon publication.] In the case of an insecure delegation, the Registrar will normally not be scanning the child zone for CDS/CDNSKEY records. The child operator can use this protocol to notify the Registrar to begin such a scan. Once the Registrar sees these records it SHOULD start acceptance @@ -320,20 +318,23 @@ 4.2.1.1.1. Request Syntax: POST /domains/{domain}/cds 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 successful completion of the request. If there are multiple CDS 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 o HTTP Status code 201 indicates a success. 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 403 indicates a failure due to an invalid challenge token. @@ -412,33 +413,37 @@ reasons. 4.2.2. Token resource Path: /domains/{domain}/token 4.2.2.1. Establish Initial Trust with Challenge 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 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.@ domain name (where @ is the apex of the child zone) prior establishing the DNSSEC initial trust. This is an additional trust control mechanism to establish the initial chain of trust. 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 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 secret token. 4.2.2.1.2. Response o HTTP Status code 200 indicates a success. A token is included in the body of the response, as a valid TXT record o HTTP Status code 404 indicates the domain does not exist. @@ -481,39 +486,39 @@ 7. Internationalization Considerations This protocol is designed for machine to machine communications. Clients and servers should use punycode [RFC3492] when operating on internationalized domain names. 8. 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 for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, . + [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from + the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/ + RFC8078, March 2017, + . + 8.2. Informative References [I-D.wallstrom-dnsop-dns-delegation-requirements] Wallstrom, P. and J. Schlyter, "DNS Delegation Requirements", draft-wallstrom-dnsop-dns-delegation- requirements-03 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, @@ -532,38 +537,45 @@ Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, . [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, DOI 10.17487/RFC7480, March 2015, . Appendix A. Document History -A.1. regext Version 02 +A.1. regext Version 03 o simplify abstract o move all justification text to Intro o added HTTP response codes for rate limiting (429), missing DS RRsets (412) o expanded on Internationalization Considerations o corrected informative/normative document references o clarify parent/Registrar references in the draft 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 (JL) o Text edits and clarifications. A.3. regext Version 01 o Rewrote Abstract and Into (MP) @@ -589,27 +601,30 @@ suggestions from Jakob Schlyter. A.8. Version 00 o First rough version Authors' Addresses Jacques Latour CIRA + Ottawa, ON Email: jacques.latour@cira.ca - Olafur Gudmundsson Cloudflare, Inc. + San Francisco, CA Email: olafur+ietf@cloudflare.com Paul Wouters Red Hat + Toronto, ON Email: paul@nohats.ca Matthew Pounsett Rightside Group, Ltd. + Toronto, ON Email: matt@conundrum.com