idnits 2.17.1 draft-ietf-regext-dnsoperator-to-rrr-protocol-02.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 (January 10, 2017) is 2635 days in the past. Is this intentional? 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-04 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 regext J. Latour 3 Internet-Draft CIRA 4 Intended status: Standards Track O. Gudmundsson 5 Expires: July 14, 2017 Cloudflare, Inc. 6 P. Wouters 7 Red Hat 8 M. Pounsett 9 Rightside Group, Ltd. 10 January 10, 2017 12 Third Party DNS operator to Registrars/Registries Protocol 13 draft-ietf-regext-dnsoperator-to-rrr-protocol-02.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 hand uses DNSSEC it necessary to make regular 27 (sometimes annual) changes to the delegation, updating DS record(s) 28 in order to track KSK rollover. Under the current model this is 29 prone to delays and errors, as the Registrant must participate in 30 updates to DS records. 32 This document describes a simple protocol that allows a third party 33 DNS operator to update DS and NS records for a delegation, in a 34 trusted manner, without involving the Registrant for each operation. 35 This same protocol can be used by Registrants. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on July 14, 2017. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Notional Conventions . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.2. RFC2119 Keywords . . . . . . . . . . . . . . . . . . . . 4 75 3. Process Overview . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Identifying the Registrar . . . . . . . . . . . . . . . . 4 77 3.2. Establishing a Chain of Trust . . . . . . . . . . . . . . 5 78 3.3. Maintaining the Chain of Trust . . . . . . . . . . . . . 5 79 3.4. Other Delegation Maintenance . . . . . . . . . . . . . . 5 80 3.5. Acceptance Processing . . . . . . . . . . . . . . . . . . 5 81 4. API Definition . . . . . . . . . . . . . . . . . . . . . . . 6 82 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7 83 4.2. RESTful Resources . . . . . . . . . . . . . . . . . . . . 7 84 4.2.1. CDS resource . . . . . . . . . . . . . . . . . . . . 7 85 4.2.2. Token resource . . . . . . . . . . . . . . . . . . . 9 86 4.3. Customized Error Messages . . . . . . . . . . . . . . . . 10 87 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 88 6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 10 89 7. Internationalization Considerations . . . . . . . . . . . . . 11 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 8.2. Informative References . . . . . . . . . . . . . . . . . 11 93 Appendix A. Document History . . . . . . . . . . . . . . . . . . 12 94 A.1. regext Version 02 . . . . . . . . . . . . . . . . . . . . 12 95 A.2. regext Version 02 not pushed . . . . . . . . . . . . . . 12 96 A.3. regext Version 01 . . . . . . . . . . . . . . . . . . . . 12 97 A.4. regext Version 00 . . . . . . . . . . . . . . . . . . . . 13 98 A.5. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 13 99 A.6. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 13 100 A.7. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 13 101 A.8. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 13 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 104 1. Introduction 106 After a domain has been registered, one of three parties will 107 maintain the DNS zone loaded on the "primary" DNS servers: the 108 Registrant, the Registrar, or a third party DNS operator. DNS 109 registration systems were originally designed around making 110 registrations easy and fast, however after registration the 111 complexity of making changes to the delegation differs for each of 112 these parties. The Registrar can make changes directly in the 113 Registry systems through some API (typically EPP [RFC5730]). The 114 Registrant is typically limited to using a web interface supplied by 115 the Registrar. A third party DNS Operator must to go through the 116 Registrant to update any delegation information. 118 In this last case, the operator must contact and engage the 119 Registrant in updating NS and DS records for the delegation. New 120 information must be communicated to the Registrant, who must submit 121 that information to the Registrar. Typically this involves cutting 122 and pasting between email and a web interface, which is error prone. 123 Furthermore, involving Registrants in this way does not scale for 124 even moderately sized DNS operators. Tracking thousands (or 125 millions) of changes sent to customers, and following up if those 126 changes are not submitted to the Registrar, or are submitted with 127 errors, is itself expensive and error prone. 129 The current system does not work well, as there are many types of 130 failures that have been reported at all levels in the registration 131 model. The failures result in either the inability to use DNSSEC or 132 in validation failures that cause the domain to become unavailable to 133 users behind validating resolvers. 135 The goal of this document is to create a protocol for establishing a 136 secure chain of trust that involves parties not in the traditional 137 Registrant/Registrar/Registry (RRR) model, and to reduce the friction 138 in maintaining DNSSEC secured delegations in these cases. It 139 describes a REST-based [RFC6690] protocol which can be used to 140 establish DNSSEC initial trust (to enable or bootstrap DNSSEC), and 141 to trigger maintenance of delegation records such as DS, NS, and glue 142 records. 144 2. Notional Conventions 146 2.1. Definitions 148 For the purposes of this draft, a third-party DNS Operator is any DNS 149 Operator responsible for a zone, where the operator is neither the 150 Registrant nor the Registrar of record for the delegation. 152 Uses of "child" and "parent" refer to the relationship between DNS 153 zone operators. In this document, unless otherwise noted, the child 154 is the third-party DNS operator and the parent is the Registry. 156 Uses of the words "Registrar" or "Registration Entity" in this 157 document may also be applied to Resellers or to Registries that 158 engage in registration activities directly with Registrants. Unless 159 otherwise noted, they are used to refer to the entity which has a 160 direct business relationship with the Registrant. 162 2.2. RFC2119 Keywords 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 3. Process Overview 170 3.1. Identifying the Registrar 172 As of publication of this document, there has never been a 173 standardized or widely deployed method for easily and scalably 174 identifying the Registar for a particular registration. 176 At this time, WHOIS [RFC3912] is the only widely deployed protocol to 177 carry such information, but WHOIS responses are unstructured text, 178 and each implementor can lay out its text responses differently. In 179 addition, Registries may include referrals in this unstructured text 180 to the WHOIS interfaces of their Registrars, and those Registrar 181 WHOIS interface in turn have their own layouts. This presents a text 182 parsing problem which is infeasible to solve. 184 RDAP, the successor to WHOIS, described in [RFC7480], solves the 185 problems of unstructured responses, and a consistently implemented 186 referral system, however at this time RDAP has yet to be deployed at 187 most Registries. 189 With no current mechanism in place to scalably discover the Registar 190 for a particular registration, the problem of automatic discovery of 191 the base URL of the API is considered out of scope of this document. 193 The authors recommend standardization of an RDAP extension to obtain 194 this information from the Registry. 196 3.2. Establishing a Chain of Trust 198 After signing the zone, the child operator needs to upload the DS 199 record(s) to the parent. The child can signal its desire to have 200 DNSSEC validation enabled by publishing one of the special DNS 201 records CDS and/or CDNSKEY as defined in [RFC7344] and 202 [I-D.ietf-dnsop-maintain-ds]. 204 [RFC Editor: The above I-D reference should be replaced with the 205 correct RFC number upon publication.] 207 In the case of an insecure delegation, the Registrar will normally 208 not be scanning the child zone for CDS/CDNSKEY records. The child 209 operator can use this protocol to notify the Registrar to begin such 210 a scan. 212 Once the Registrar sees these records it SHOULD start acceptance 213 processing. 215 3.3. Maintaining the Chain of Trust 217 One the secure chain of trust is established, the Registrar SHOULD 218 regularly check the child zone for CDS/CDNSKEY record changes. The 219 Registrar SHOULD also accept signals via this protocol to immediately 220 check the child zone for CDS/CDNSKEY records. 222 Server implementations of this protocol MAY include rate limiting to 223 protect their systems and the systems of child operators from abuse. 225 Each parent operator and Registrar is responsible for developing, 226 implementing, and communicating their DNSSEC maintenance policies. 228 3.4. Other Delegation Maintenance 230 [ Not yet defined ] 232 3.5. Acceptance Processing 234 The Registrar, upon receiving a signal or detecting through polling 235 that the child desires to have its delegation updated, SHOULD run a 236 series of tests to ensure that updating the parent zone will not 237 create or exacerbate any problems with the child zone. The basic 238 tests SHOULD include: 240 o checking that the child zone is is properly signed as per the 241 Registrar and parent DNSSEC policy 243 o if updating the DS record, checking that the child CDS RRset 244 references a KSK which is present in the child DNSKEY RRset and 245 signs the CDS RRset 247 o ensuring all name servers in the apex NS RRset of the child zone 248 agree on the apex NS RRset and CDS RRset contents 250 The Registrar SHOULD NOT make any changes to the DS RRset if the 251 child name servers do not agree on the CDS/CDNSKEY content. 253 [NOTE: Do we need a new section in the DPS for the CDS management 254 policy [RFC6841]?] 256 Registrars MAY require compliance with additional tests, particularly 257 in the case of establishing a new chain of trust, such as: 259 o checking that all child name servers to respond with a consistent 260 CDS/CDNSKEY RRset for a number of queries over an extended period 261 of time to minimise the possibility of an attacker spoofing 262 responses 264 o requiring the child name servers to respond with identical CDS/ 265 CDNSKEY RRsets over TCP 267 o ensuring zone delegation best practices (for examples, see 268 [I-D.wallstrom-dnsop-dns-delegation-requirements] 270 o requiring the child operator to prove they can add data to the 271 zone (for example, by publishing a particular token) 273 4. API Definition 275 This protocol is partially synchronous, meaning the server can elect 276 to hold connections open until operations have completed, or it can 277 return a status code indicating that it has received a request, and 278 close the connection. It is up to the child to monitor the parent 279 for completion of the operation, and issue possible follow-up calls 280 to the Registrar. 282 Clients may be denied access to change the DS records for domains 283 that are Registry Locked (HTTP Status code 401). Registry Lock is a 284 mechanism provided by certain Registries or Registrars that prevents 285 domain hijacking by ensuring no attributes of the domain are 286 changeable, and no transfer or deletion transactions can be processed 287 against the domain name without manual intervention. 289 4.1. Authentication 291 The API does not impose any unique server authentication 292 requirements. The server authentication provided by TLS fully 293 addresses the needs of this protocol. The API MUST be provided over 294 TLS-protected transport (e.g., HTTPS) or VPN. 296 Client authentication is considered out of scope of this document. 297 The publication of CDS/CDNSKEY records in the child zone is an 298 indication that the child operator intends to perform DS-record- 299 updating activities (add/delete) in the parent zone. Since this 300 protocol is simply a signal to the Registrar that they should examine 301 the child zone for such intentions, additional authentication of the 302 client making the request is considered unnecessary. 304 Registrars MAY implement their own policy to protect access to the 305 API, such as with IP whitelisting, client TLS certificates, etc.. 306 Registrars SHOULD take steps to ensure that a lack of additional 307 authentication does not open up a denial of service mechanism against 308 the systems of the Registrar, the Registry, or the child operator. 310 4.2. RESTful Resources 312 In the following text, "{domain}" is the child zone to be operated 313 on. 315 4.2.1. CDS resource 317 Path: /domains/{domain}/cds 319 4.2.1.1. Establishing Initial Trust (Enabling DNSSEC) 321 4.2.1.1.1. Request 323 Syntax: POST /domains/{domain}/cds 325 Request that an initial set of DS records based on the CDS record in 326 the child zone be inserted into the Registry and the parent zone upon 327 the successful completion of the request. If there are multiple CDS 328 records in the CDS RRset, multiple DS records will be added. 330 4.2.1.1.2. Response 332 o HTTP Status code 201 indicates a success. 334 o HTTP Status code 400 indicates a failure due to validation. 336 o HTTP Status code 401 indicates an unauthorized resource access. 338 o HTTP Status code 403 indicates a failure due to an invalid 339 challenge token. 341 o HTTP Status code 404 indicates the domain does not exist. 343 o HTTP Status code 409 indicates the delegation already has a DS 344 RRset. 346 o HTTP Status code 429 indicates the client has been rate-limited. 348 o HTTP Status code 500 indicates a failure due to unforeseeable 349 reasons. 351 This request is for setting up initial trust in the delegation. The 352 Registrar SHOULD return a status code 409 if it already has a DS 353 RRset for the child zone. 355 Upon receipt of a 403 response the child operator SHOULD issue a POST 356 for the "token" resource to fetch a challenge token to insert into 357 the zone. 359 4.2.1.2. Removing DS Records 361 4.2.1.2.1. Request 363 Syntax: DELETE /domains/{domain}/cds 365 Request that the Registrar check for a null CDS or CDNSKEY record in 366 the child zone, indicating a request that the entire DS RRset be 367 removed. This will make the delegation insecure. 369 4.2.1.2.2. Response 371 o HTTP Status code 200 indicates a success. 373 o HTTP Status code 400 indicates a failure due to validation. 375 o HTTP Status code 401 indicates an unauthorized resource access. 377 o HTTP Status code 404 indicates the domain does not exist. 379 o HTTP Status code 412 indicates the parent does not have a DS RRset 381 o HTTP Status code 429 indicates the client has been rate-limited. 383 o HTTP Status code 500 indicates a failure due to unforeseeable 384 reasons. 386 4.2.1.3. Modifying DS Records 388 4.2.1.3.1. Request 390 Syntax: PUT /domains/{domain}/cds 392 Request that the Registrar modify the DS RRset based on the CDS/ 393 CDNSKEY available in the child zone. As a result of this request the 394 Registrar SHOULD add or delete DS records as indicated by the CDS/ 395 CDNSKEY RRset, but MUST NOT delete the entire DS RRset. 397 4.2.1.3.2. Response 399 o HTTP Status code 200 indicates a success. 401 o HTTP Status code 400 indicates a failure due to validation. 403 o HTTP Status code 401 indicates an unauthorized resource access. 405 o HTTP Status code 404 indicates the domain does not exist. 407 o HTTP Status code 412 indicates the parent does not have a DS RRset 409 o HTTP Status code 429 indicates the client has been rate-limited. 411 o HTTP Status code 500 indicates a failure due to unforeseeable 412 reasons. 414 4.2.2. Token resource 416 Path: /domains/{domain}/token 418 4.2.2.1. Establish Initial Trust with Challenge 420 4.2.2.1.1. Request 422 Syntax: POST /domains/{domain}/token 424 The DNSSEC policy of the Registrar may require proof that the DNS 425 Operator is in control of the domain. The token API call returns a 426 random token to be included as a TXT record for the _delegate.@ 427 domain name (where @ is the apex of the child zone) prior 428 establishing the DNSSEC initial trust. This is an additional trust 429 control mechanism to establish the initial chain of trust. 431 Once the child operator has received a token, it SHOULD be inserted 432 in the zone and the operator SHOULD proceed with a POST of the cds 433 resource. 435 Note that the _delegate TXT record is publicly available and not a 436 secret token. 438 4.2.2.1.2. Response 440 o HTTP Status code 200 indicates a success. A token is included in 441 the body of the response, as a valid TXT record 443 o HTTP Status code 404 indicates the domain does not exist. 445 o HTTP Status code 500 indicates a failure due to unforeseeable 446 reasons. 448 4.3. Customized Error Messages 450 Registrars MAY provide a customized error message in the response 451 body in addition to the HTTP status code defined in the previous 452 section. This response MAY include an identifying number/string that 453 can be used to track the request. 455 5. Security considerations 457 When zones are properly provisioned, and delegations follow standards 458 and best practices (e.g. 459 [I-D.wallstrom-dnsop-dns-delegation-requirements]), the Registrar or 460 Registry can trust the DNS information it receives from multiple 461 child name servers, over time, and/or over TCP to establish the 462 initial chain of trust. 464 In addition, the Registrar or Registry can require the DNS Operator 465 to prove they control the zone by requiring the child operator to 466 navigate additional hurdles, such as adding a challenge token to the 467 zone. 469 This protocol should increase the adoption of DNSSEC, enabling more 470 zones to become validated thus overall the security gain outweighs 471 the possible drawbacks. 473 Registrants and DNS Operators always have the option to establish the 474 chain of trust in band via the standard Registrant/Registrar/Registry 475 model. 477 6. IANA Actions 479 This document has no actions for IANA 481 7. Internationalization Considerations 483 This protocol is designed for machine to machine communications. 484 Clients and servers should use punycode [RFC3492] when operating on 485 internationalized domain names. 487 8. References 489 8.1. Normative References 491 [I-D.ietf-dnsop-maintain-ds] 492 Gudmundsson, O. and P. Wouters, "Managing DS records from 493 parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-04 494 (work in progress), October 2016. 496 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 497 for Internationalized Domain Names in Applications 498 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 499 . 501 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 502 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 503 . 505 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 506 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 507 10.17487/RFC7344, September 2014, 508 . 510 8.2. Informative References 512 [I-D.wallstrom-dnsop-dns-delegation-requirements] 513 Wallstrom, P. and J. Schlyter, "DNS Delegation 514 Requirements", draft-wallstrom-dnsop-dns-delegation- 515 requirements-03 (work in progress), October 2016. 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 519 RFC2119, March 1997, 520 . 522 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 523 10.17487/RFC3912, September 2004, 524 . 526 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 527 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 528 . 530 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 531 Framework for DNSSEC Policies and DNSSEC Practice 532 Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, 533 . 535 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 536 Registration Data Access Protocol (RDAP)", RFC 7480, DOI 537 10.17487/RFC7480, March 2015, 538 . 540 Appendix A. Document History 542 A.1. regext Version 02 544 o simplify abstract 546 o move all justification text to Intro 548 o added HTTP response codes for rate limiting (429), missing DS 549 RRsets (412) 551 o expanded on Internationalization Considerations 553 o corrected informative/normative document references 555 o clarify parent/Registrar references in the draft 557 o general spelling/grammar/style cleanup 559 A.2. regext Version 02 not pushed 561 o Clarified based on comments and questions from early implementors 562 (JL) 564 o Text edits and clarifications. 566 A.3. regext Version 01 568 o Rewrote Abstract and Into (MP) 570 o Introduced code 401 when changes are not allowed 572 o Text edits and clarifications. 574 A.4. regext Version 00 576 o Working group document same as 03, just track changed to standard 578 A.5. Version 03 580 o Clarified based on comments and questions from early implementors 582 A.6. Version 02 584 o Reflected comments on mailing lists 586 A.7. Version 01 588 o This version adds a full REST definition this is based on 589 suggestions from Jakob Schlyter. 591 A.8. Version 00 593 o First rough version 595 Authors' Addresses 597 Jacques Latour 598 CIRA 600 Email: jacques.latour@cira.ca 602 Olafur Gudmundsson 603 Cloudflare, Inc. 605 Email: olafur+ietf@cloudflare.com 607 Paul Wouters 608 Red Hat 610 Email: paul@nohats.ca 612 Matthew Pounsett 613 Rightside Group, Ltd. 615 Email: matt@conundrum.com