idnits 2.17.1 draft-ietf-regext-dnsoperator-to-rrr-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 26, 2016) is 2922 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-maintain-ds-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Latour 3 Internet-Draft CIRA 4 Intended status: Standards Track O. Gudmundsson 5 Expires: October 28, 2016 Cloudflare, Inc. 6 P. Wouters 7 Red Hat 8 M. Pounsett 9 Rightside Group, Ltd. 10 April 26, 2016 12 Third Party DNS operator to Registrars/Registries Protocol 13 draft-ietf-regext-dnsoperator-to-rrr-protocol-00.txt 15 Abstract 17 There are several problems that arise in the standard 18 Registrant/Registrar/Registry model when the operator of a zone is 19 neither the Registrant nor the Registrar for the delegation. 20 Historically the issues have been minor, and limited to difficulty 21 guiding the Registrant through the initial changes to the NS records 22 for the delegation. As this is usually a one time activity when the 23 operator first takes charge of the zone it has not been treated as a 24 serious issue. 26 When the domain on the other hand uses DNSSEC it necessary for the 27 Registrant in this situation to make regular (sometimes annual) 28 changes to the delegation in order to track KSK rollover, by updating 29 the delegation's DS record(s). Under the current model this is prone 30 to Registrant error and significant delays. Even when the Registrant 31 has outsourced the operation of DNS to a third party the registrant 32 still has to be in the loop to update the DS record. 34 There is a need for a simple protocol that allows a third party DNS 35 operator to update DS and NS records in a trusted manner for a 36 delegation without involving the registrant for each operation. 38 The protocol described in this draft is REST based, and when used 39 through an authenticated channel can be used to establish the DNSSEC 40 Initial Trust (to turn on DNSSEC or bootstrap DNSSEC). Once DNSSEC 41 trust is established this channel can be used to trigger maintenance 42 of delegation records such as DS, NS, and glue records. The protocol 43 is kept as simple as possible. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on October 28, 2016. 62 Copyright Notice 64 Copyright (c) 2016 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Notional Conventions . . . . . . . . . . . . . . . . . . . . 4 81 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 82 2.2. RFC2119 Keywords . . . . . . . . . . . . . . . . . . . . 4 83 3. What is the goal? . . . . . . . . . . . . . . . . . . . . . . 4 84 3.1. Why DNSSEC? . . . . . . . . . . . . . . . . . . . . . . . 4 85 3.2. How does a child signal its parent it wants DNSSEC Trust 86 Anchor? The child . . . . . . . . . . . . . . . . . . . 4 87 3.3. What checks are needed by parent? . . . . . . . . . . . . 5 88 4. OP-3-DNS-RR RESTful API . . . . . . . . . . . . . . . . . . . 5 89 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 6 90 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 6 91 4.3. Base URL Locator . . . . . . . . . . . . . . . . . . . . 6 92 4.4. CDS resource . . . . . . . . . . . . . . . . . . . . . . 6 93 4.4.1. Initial Trust Establishment (Enable DNSSEC 94 validation) . . . . . . . . . . . . . . . . . . . . . 6 95 4.4.2. Removing a DS (turn off DNSSEC) . . . . . . . . . . . 7 96 4.4.3. DS Maintenance (Key roll over) . . . . . . . . . . . 7 97 4.5. Tokens resource . . . . . . . . . . . . . . . . . . . . . 7 98 4.5.1. Setup Initial Trust Establishment with Challenge . . 8 99 4.6. Customized Error Messages . . . . . . . . . . . . . . . . 8 100 4.7. How to react to 403 on POST cds . . . . . . . . . . . . . 8 101 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 102 6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 9 103 7. Internationalization Considerations . . . . . . . . . . . . . 9 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 105 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 106 8.2. Informative References . . . . . . . . . . . . . . . . . 9 107 Appendix A. Document History . . . . . . . . . . . . . . . . . . 10 108 A.1. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 10 109 A.2. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 10 110 A.3. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 10 111 A.4. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 10 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 114 1. Introduction 116 Why is this needed? DNS registration systems today are designed 117 around making registrations easy and fast. After the domain has been 118 registered the there are really three options on who maintains the 119 DNS zone that is loaded on the "primary" DNS servers for the domain 120 this can be the Registrant, Registrar, or a third party DNS Operator. 122 Unfortunately the ease to make changes differs for each one of these 123 options. The Registrant needs to use the interface that the 124 registrar provides to update NS and DS records. The Registrar on the 125 other hand can make changes directly into the registration system. 126 The third party DNS Operator on the hand needs to go through the 127 Registrant to update any delegation information. 129 Current system does not work well, there are many examples of 130 failures including the inability to upload DS records due to non- 131 support by Registrar interface, the registrant forgets/does-not 132 perform action but tools proceed with key roll-over without checking 133 that the new DS is in place. Another common failure is the DS record 134 is not removed when the DNS Operator changes from one that supports 135 DNSSEC signing to one that does not. 137 The failures result either inability to use DNSSEC or in validation 138 failures that case the domain to become invalid and all users that 139 are behind validating resolvers will not be able to to access the 140 domain. 142 2. Notional Conventions 144 2.1. Definitions 146 For the purposes of this draft, a third-party DNS Operator is any DNS 147 Operator responsible for a zone where the operator is neither the 148 Registrant nor the Registrar of record for the delegation. 150 Uses of the word 'Registrar' in this document may also be applied to 151 resellers: an entity that sells delegations through a registrar with 152 whom the entity has a reseller agreement. 154 2.2. RFC2119 Keywords 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 3. What is the goal? 162 The primary goal is to use the DNS protocol to provide information 163 from child zone to the parent zone, to maintain the delegation 164 information. The precondition for this to be practical is that the 165 domain is DNSSEC signed. 167 In the general case there should be a way to find the right 168 Registrar/Registry entity to talk to but that does not exist. 169 Whois[] is the natural protocol to carry such information but that 170 protocol is unreliable and hard to parse. Its proposed successor 171 RDAP [RFC7480] has yet be deployed on most TLD's. 173 The preferred communication mechanism is to use is to use a REST 174 [RFC6690] call to start processing of the requested delegation 175 information. 177 3.1. Why DNSSEC? 179 DNSSEC [RFC4035] provides data authentication for DNS answers, having 180 DNSSEC enabled makes it possible to trust the answers. The biggest 181 stumbling block is deploying DNSSEC is the initial configuration of 182 the DNSSEC domain trust anchor in the parent, DS record. 184 3.2. How does a child signal its parent it wants DNSSEC Trust Anchor? 185 The child 187 needs first to sign the domain, then the child can "upload" the DS 188 record to its parent. The "normal" way to upload is to go through 189 registration interface, but that fails frequently. The DNS Operator 190 may not have access to the interface thus the registrant needs to 191 relay the information. For large operations this does not scale, as 192 evident in lack of Trust Anchors for signed deployments that are 193 operated by third parties. 195 The child can signal its desire to have DNSSEC validation enabled by 196 publishing one of the special DNS records CDS and/or CDNSKEY[RFC7344] 197 and its proposed extension [I-D.ietf-dnsop-maintain-ds]. 199 Once the "parent" "sees" these records it SHOULD start acceptance 200 processing. This document will cover below how to make the CDS 201 records visible to the right parental agent. 203 We and [I-D.ogud-dnsop-maintain-ds] argue that the publication of 204 CDS/CDNSKEY record is sufficient for the parent to start the 205 acceptance processing. The main point is to provide authentication 206 thus if the child is in "good" state then the DS upload should be 207 simple to accept and publish. If there is a problem the parent has 208 ability to not add the DS. 210 3.3. What checks are needed by parent? 212 The parent upon receiving a signal that it check the child for desire 213 for DS record publication. The basic tests include, 215 1. The zone is signed 216 2. The zone has a CDS signed by a KSK referenced in the current DS, 217 referring to a at least one key in the current DNSKEY RRset 218 3. All the name-servers for the zone agree on the CDS RRset contents 220 Parents can have additional tests, defined delays, queries over TCP, 221 and even ask the DNS Operator to prove they can add data to the zone, 222 or provide a code that is tied to the affected zone. The protocol is 223 partially-synchronous, i.e. the server can elect to hold connection 224 open until the operation has concluded or it can return that it 225 received the request. It is up to the child to monitor the parent 226 for completion of the operation and issue possible follow-up calls. 228 4. OP-3-DNS-RR RESTful API 230 The specification of this API is minimalist, but a realistic one. 231 Question: How to respond if the party contacted is not ALLOWED to 232 make the requested change? 234 4.1. Authentication 236 The API does not impose any unique server authentication 237 requirements. The server authentication provided by TLS fully 238 addresses the needs. In general, for the API SHOULD be provided over 239 TLS-protected transport (e.g., HTTPS) or VPN. 241 4.2. Authorization 243 Authorization is out of scope of this document. The CDS records 244 present in the zone file are indications of intention to sign/unsign/ 245 update the DS records of the domain in the parent zone. This means 246 the proceeding of the action is not determined by who issued the 247 request. Therefore, authorization is out of the scope. Registries 248 and registrars who plan to provide this service can, however, 249 implement their own policy such as IP white listing, API key, etc. 251 4.3. Base URL Locator 253 The base URL for registries or registrars who want to provide this 254 service to DNS Operators can be made auto-discoverable as an RDAP 255 extension. 257 4.4. CDS resource 259 Path: /domains/{domain}/cds {domain}: is the domain name to be 260 operated on 262 4.4.1. Initial Trust Establishment (Enable DNSSEC validation) 264 4.4.1.1. Request 266 Syntax: POST /domains/{domain}/cds 268 A DS record based on the CDS record in the child zone file will be 269 inserted into the registry and the parent zone file upon the 270 successful completion of such request. If there are multiple CDS 271 records in the CDS RRset, multiple DS records will be added. 273 Either the CDS/CDNSKEY or the DNSKEY can be used to create the DS 274 record. Note: entity expecting CDNSKEY is still expected accept the 275 /cds command. 277 4.4.1.2. Response 279 o HTTP Status code 201 indicates a success. 281 o HTTP Status code 400 indicates a failure due to validation. 283 o HTTP Status code 403 indicates a failure due to an invalid 284 challenge token. 286 o HTTP Status code 404 indicates the domain does not exist. 288 o HTTP Status code 500 indicates a failure due to unforeseeable 289 reasons. 291 4.4.2. Removing a DS (turn off DNSSEC) 293 4.4.2.1. Request 295 Syntax: DELETE /domains/{domain}/cds 297 4.4.2.2. Response 299 o HTTP Status code 200 indicates a success. 301 o HTTP Status code 400 indicates a failure due to validation. 303 o HTTP Status code 404 indicates the domain does not exist. 305 o HTTP Status code 500 indicates a failure due to unforeseeable 306 reasons. 308 4.4.3. DS Maintenance (Key roll over) 310 4.4.3.1. Request 312 Syntax: PUT /domains/{domain}/cds 314 4.4.3.2. Response 316 o HTTP Status code 200 indicates a success. 318 o HTTP Status code 400 indicates a failure due to validation. 320 o HTTP Status code 404 indicates the domain does not exist. 322 o HTTP Status code 500 indicates a failure due to unforeseeable 323 reasons. 325 4.5. Tokens resource 327 Path: /domains/{domain}/tokens {domain}: is the domain name to be 328 operated on 330 4.5.1. Setup Initial Trust Establishment with Challenge 332 4.5.1.1. Request 334 Syntax: POST /domains/{domain}/tokens 336 A random token to be included as a _delegate TXT record prior 337 establishing the DNSSEC initial trust. 339 4.5.1.2. Response 341 o HTTP Status code 200 indicates a success. Token included in the 342 body of the response, as a valid TXT record 344 o HTTP Status code 404 indicates the domain does not exist. 346 o HTTP Status code 500 indicates a failure due to unforeseeable 347 reasons. 349 4.6. Customized Error Messages 351 Service providers can provide a customized error message in the 352 response body in addition to the HTTP status code defined in the 353 previous section. 355 This can include an Identifiying number/string that can be used to 356 track the requests. 358 #Using the definitions This section at the moment contains comments 359 from early implementers 361 4.7. How to react to 403 on POST cds 363 The basic reaction to a 403 on POST /domains/{domain}/cds is to issue 364 POST /domains/{domain}/tokens command to fetch the challenge to 365 insert into the zone. 367 5. Security considerations 369 TBD This will hopefully get more zones to become validated thus 370 overall the security gain out weights the possible drawbacks. 372 risk of takeover ? risk of validation errors < declines transfer 373 issues 375 6. IANA Actions 377 URI ??? TBD 379 7. Internationalization Considerations 381 This protocol is designed for machine to machine communications 383 8. References 385 8.1. Normative References 387 [I-D.ietf-dnsop-maintain-ds] 388 Gu[eth]mundsson, O. and P. Wouters, "Managing DS records 389 from parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain- 390 ds-00 (work in progress), December 2015. 392 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 393 Rose, "Protocol Modifications for the DNS Security 394 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 395 . 397 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 398 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 399 10.17487/RFC7344, September 2014, 400 . 402 8.2. Informative References 404 [I-D.ogud-dnsop-maintain-ds] 405 Gu[eth]mundsson, O. and P. Wouters, "Managing DS records 406 from parent via CDS/CDNSKEY", draft-ogud-dnsop-maintain- 407 ds-00 (work in progress), October 2015. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 411 RFC2119, March 1997, 412 . 414 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 415 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 416 . 418 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 419 Registration Data Access Protocol (RDAP)", RFC 7480, DOI 420 10.17487/RFC7480, March 2015, 421 . 423 Appendix A. Document History 425 A.1. Version 03 427 Clarified based on comments and questions from early implementors 429 A.2. Version 02 431 Reflected comments on mailing lists 433 A.3. Version 01 435 This version adds a full REST definition this is based on suggestions 436 from Jakob Schlyter. 438 A.4. Version 00 440 First rough version 442 Authors' Addresses 444 Jacques Latour 445 CIRA 447 Email: jacques.latour@cira.ca 449 Olafur Gudmundsson 450 Cloudflare, Inc. 452 Email: olafur+ietf@cloudflare.com 454 Paul Wouters 455 Red Hat 457 Email: paul@nohats.ca 459 Matthew Pounsett 460 Rightside Group, Ltd. 462 Email: matt@conundrum.com