idnits 2.17.00 (12 Aug 2021) /tmp/idnits56612/draft-ietf-regext-dnsoperator-to-rrr-protocol-01.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 (July 7, 2016) is 2144 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: draft-ietf-dnsop-maintain-ds has been published as RFC 8078 == Outdated reference: A later version (-03) exists of draft-wallstrom-dnsop-dns-delegation-requirements-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: January 8, 2017 Cloudflare, Inc. 6 P. Wouters 7 Red Hat 8 M. Pounsett 9 Rightside Group, Ltd. 10 July 7, 2016 12 Third Party DNS operator to Registrars/Registries Protocol 13 draft-ietf-regext-dnsoperator-to-rrr-protocol-01.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 to make 27 regular (sometimes annual) changes to the delegation, in order to 28 track KSK rollover, by updating the delegation's DS record(s). Under 29 the current model this is prone to delays and errors. Even when the 30 Registrant has outsourced the operation of DNS to a third party the 31 registrant still has to be in the loop to update the DS record. 33 There is a need for a simple protocol that allows a third party DNS 34 operator to update DS and NS records in a trusted manner for a 35 delegation without involving the registrant for each operation. This 36 same protocol can be used by Registrants. 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 January 8, 2017. 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? . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 3.3. What checks are needed by parent? . . . . . . . . . . . . 5 88 4. Third Party DNS operator to Registrars/Registries RESTful API 6 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) . . . . . . . . . . . 8 97 4.5. Tokens resource . . . . . . . . . . . . . . . . . . . . . 8 98 4.5.1. Setup Initial Trust Establishment with Challenge . . 8 99 4.6. Customized Error Messages . . . . . . . . . . . . . . . . 9 100 4.7. How to react to 403 on POST cds . . . . . . . . . . . . . 9 101 5. Security considerations . . . . . . . . . . . . . . . . . . . 9 102 6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 9 103 7. Internationalization Considerations . . . . . . . . . . . . . 10 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 105 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 106 8.2. Informative References . . . . . . . . . . . . . . . . . 10 107 Appendix A. Document History . . . . . . . . . . . . . . . . . . 11 108 A.1. Regex versio 01 . . . . . . . . . . . . . . . . . . . . . 11 109 A.2. Regex version 00 . . . . . . . . . . . . . . . . . . . . 11 110 A.3. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 11 111 A.4. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 11 112 A.5. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 11 113 A.6. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 11 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 116 1. Introduction 118 Why is this needed? DNS registration systems today are designed 119 around making registrations easy and fast. After the domain has been 120 registered there are really three options on who maintains the DNS 121 zone that is loaded on the "primary" DNS servers for the domain this 122 can be the Registrant, Registrar, or a third party DNS Operator. 124 Unfortunately the ease to make changes differs for each one of these 125 options. The Registrant needs to use the interface that the 126 registrar provides to update NS and DS records. The Registrar on the 127 other hand can make changes directly into the registration system. 128 The third party DNS Operator on the hand needs to go through the 129 Registrant to update any delegation information. 131 Current system does not work well, there are many types of failures 132 have been reported and they have been at all levels in the 133 registration model. 135 The failures result either inability to use DNSSEC or in validation 136 failures that case the domain to become invalid and all users that 137 are behind validating resolvers will not be able to to access the 138 domain. 140 The goal of this document is to create an automated interface that 141 will reduce the friction in maintaining DNSSEC delegations. 143 2. Notional Conventions 145 2.1. Definitions 147 For the purposes of this draft, a third-party DNS Operator is any DNS 148 Operator responsible for a zone where the operator is neither the 149 Registrant nor the Registrar of record for the delegation. 151 Uses of the word 'Registrar' in this document may also be applied to 152 resellers: an entity that sells delegations through a registrar with 153 whom the entity has a reseller agreement. 155 2.2. RFC2119 Keywords 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 3. What is the goal? 163 The primary goal is to have a protocol to establish a secure chain of 164 trust that involves parties that are not in the traditional RRR EPP 165 model, or when EPP is not used. 167 In the general case there should be a way to find the right 168 Registrar/Registry entity to talk to, but it does not exist. Whois[] 169 is the natural protocol to carry such information but that protocol 170 but is unreliable and hard to parse. Its proposed successor RDAP 171 [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 obstacle in DNSSEC adoption is the initial configuration of the 182 DNSSEC domain trust anchor at the parent, the DS record. 184 3.2. How does a child signal its parent it wants DNSSEC Trust Anchor? 186 The child needs first to sign the domain, then the child can "upload" 187 the DS record to its parent. The "normal" way to upload is to go 188 through registration interface, but that fails frequently. The DNS 189 Operator may not have access to the interface thus the registrant 190 needs to relay the information. For large operations this does not 191 scale, as evident in lack of Trust Anchors for signed deployments 192 that are operated by third parties. 194 The child can signal its desire to have DNSSEC validation enabled by 195 publishing one of the special DNS records CDS and/or CDNSKEY[RFC7344] 196 and its proposed extension [I-D.ietf-dnsop-maintain-ds]. 198 Once the "parent" "sees" these records it SHOULD start acceptance 199 processing. This document covers how to make the CDS records visible 200 to the right parental agent. 202 This document and [I-D.ogud-dnsop-maintain-ds] argue that the 203 publication of CDS/CDNSKEY record is sufficient for the parent to 204 start the acceptance processing. The main point is to provide 205 authentication thus if the child is in "good" state then the DS 206 upload should be simple to accept and publish. If there is any 207 problem the parent does not add the DS. 209 In the event this protocols and its associated authentication 210 mechanism does not address the Registrant's security requirements to 211 create a secure Trust Anchor delegation then the Registrant always 212 has recourse by submitting its DS record via its Registrar interface 213 with EPP submission to the Registry. 215 3.3. What checks are needed by parent? 217 The parent upon receiving a signal that it check the child for desire 218 for DS record publication. The basic tests include, 220 1. Is the zone is signed 221 2. The zone has a CDS signed by a KSK referenced in the current DS, 222 referring to a at least one key in the current DNSKEY RRset 223 3. All the name-servers for the zone agree on the CDS RRset contents 225 Parents can perform additional tests, defined delays, queries over 226 TCP, ensure zone delegation best practice as per 227 [I-D.wallstrom-dnsop-dns-delegation-requirements] and even ask the 228 DNS Operator to prove they can add data to the zone, or provide a 229 code that is tied to the affected zone. The protocol is partially- 230 synchronous, i.e. the server can elect to hold connection open until 231 the operation has concluded or it can return that it received the 232 request. It is up to the child to monitor the parent for completion 233 of the operation and issue possible follow-up calls. 235 4. Third Party DNS operator to Registrars/Registries RESTful API 237 The specification of this API is minimalist, but a realistic one. 239 Registry Lock mechanisms that prevents domain hijacking block domains 240 prevent certain attributes in the registry to be changed. This API 241 may be denied access to change the DS records for domains that are 242 Registry Locked (HTTP Status code 401). 244 4.1. Authentication 246 The API does not impose any unique server authentication 247 requirements. The server authentication provided by TLS fully 248 addresses the needs. In general, the API SHOULD be provided over 249 TLS-protected transport (e.g., HTTPS) or VPN. 251 4.2. Authorization 253 Authorization is outside the scope of this document. The CDS records 254 present in the zone file are indications of intention to sign/unsign/ 255 update the DS records of the domain in the parent zone. This means 256 the proceeding of the action is not determined by who issued the 257 request. Therefore, authorization is out of scope. Registries and 258 registrars who plan to provide this service can, however, implement 259 their own policy such as IP white listing, API key, etc. 261 4.3. Base URL Locator 263 The base URL for registries or registrars who want to provide this 264 service to DNS Operators can be made auto-discoverable as an RDAP 265 extension. 267 4.4. CDS resource 269 Path: /domains/{domain}/cds {domain}: is the domain name to be 270 operated on 272 4.4.1. Initial Trust Establishment (Enable DNSSEC validation) 274 4.4.1.1. Request 276 Syntax: POST /domains/{domain}/cds 278 A DS record based on the CDS record in the child zone file will be 279 inserted into the registry and the parent zone file upon the 280 successful completion of such request. If there are multiple CDS 281 records in the CDS RRset, multiple DS records will be added. 283 Either the CDS/CDNSKEY or the DNSKEY can be used to create the DS 284 record. Note: entity expecting CDNSKEY is still expected accept the 285 /cds command. 287 4.4.1.2. Response 289 o HTTP Status code 201 indicates a success. 291 o HTTP Status code 400 indicates a failure due to validation. 293 o HTTP Status code 401 indicates an unauthorized resource access. 295 o HTTP Status code 403 indicates a failure due to an invalid 296 challenge token. 298 o HTTP Status code 404 indicates the domain does not exist. 300 o HTTP Status code 500 indicates a failure due to unforeseeable 301 reasons. 303 4.4.2. Removing a DS (turn off DNSSEC) 305 4.4.2.1. Request 307 Syntax: DELETE /domains/{domain}/cds 309 A null CDS or CDNSKEY record mean the entire DS RRset must be 310 removed. 312 4.4.2.2. Response 314 o HTTP Status code 200 indicates a success. 316 o HTTP Status code 400 indicates a failure due to validation. 318 o HTTP Status code 401 indicates an unauthorized resource access. 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.4.3. DS Maintenance (Key roll over) 327 4.4.3.1. Request 329 Syntax: PUT /domains/{domain}/cds 331 Maintenance activities are performed based on the CDS available in 332 the child zone. DS records may be added, removed. But the entire DS 333 RRset must not be deleted. 335 4.4.3.2. Response 337 o HTTP Status code 200 indicates a success. 339 o HTTP Status code 400 indicates a failure due to validation. 341 o HTTP Status code 401 indicates an unauthorized resource access. 343 o HTTP Status code 404 indicates the domain does not exist. 345 o HTTP Status code 500 indicates a failure due to unforeseeable 346 reasons. 348 4.5. Tokens resource 350 Path: /domains/{domain}/tokens {domain}: is the domain name to be 351 operated on 353 4.5.1. Setup Initial Trust Establishment with Challenge 355 4.5.1.1. Request 357 Syntax: POST /domains/{domain}/tokens 359 A random token to be included as a _delegate TXT record prior 360 establishing the DNSSEC initial trust. 362 4.5.1.2. Response 364 o HTTP Status code 200 indicates a success. Token included in the 365 body of the response, as a valid TXT record 367 o HTTP Status code 404 indicates the domain does not exist. 369 o HTTP Status code 500 indicates a failure due to unforeseeable 370 reasons. 372 4.6. Customized Error Messages 374 Service providers can provide a customized error message in the 375 response body in addition to the HTTP status code defined in the 376 previous section. 378 This can include an Identifying number/string that can be used to 379 track the requests. 381 #Using the definitions This section at the moment contains comments 382 from early implementers 384 4.7. How to react to 403 on POST cds 386 The basic reaction to a 403 on POST /domains/{domain}/cds is to issue 387 POST /domains/{domain}/tokens command to fetch the challenge to 388 insert into the zone. 390 5. Security considerations 392 Supplying the DS record as proof of control is not realistic since 393 the domain is already publicly signed and the CDS/DS is readily 394 available. 396 Open question:?? JL?: It is not recommended the protocol be used with 397 high profile domains such as TLDs and governments that are DNS 398 operators. This protocol is meant to allow third party DNS operator 399 to submit the initial DS in a trusted manner without involving the 400 registrant. 402 This protocol should increase the adoption of DNSSEC and get more 403 zones to become validated thus overall the security gain outweighs 404 the possible drawbacks. 406 TBD This will hopefully get more zones to become validated thus 407 overall the security gain out weights the possible drawbacks. 409 risk of takeover ? risk of validation errors < declines transfer 410 issues 412 6. IANA Actions 414 URI ??? TBD 416 7. Internationalization Considerations 418 This protocol is designed for machine to machine communications 420 8. References 422 8.1. Normative References 424 [I-D.ietf-dnsop-maintain-ds] 425 Gudmundsson, O. and P. Wouters, "Managing DS records from 426 parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-03 427 (work in progress), June 2016. 429 [I-D.wallstrom-dnsop-dns-delegation-requirements] 430 Wallstrom, P. and J. Schlyter, "DNS Delegation 431 Requirements", draft-wallstrom-dnsop-dns-delegation- 432 requirements-00 (work in progress), February 2016. 434 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 435 Rose, "Protocol Modifications for the DNS Security 436 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 437 . 439 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 440 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 441 10.17487/RFC7344, September 2014, 442 . 444 8.2. Informative References 446 [I-D.ogud-dnsop-maintain-ds] 447 Gu[eth]mundsson, O. and P. Wouters, "Managing DS records 448 from parent via CDS/CDNSKEY", draft-ogud-dnsop-maintain- 449 ds-00 (work in progress), October 2015. 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 453 RFC2119, March 1997, 454 . 456 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 457 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 458 . 460 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 461 Registration Data Access Protocol (RDAP)", RFC 7480, DOI 462 10.17487/RFC7480, March 2015, 463 . 465 Appendix A. Document History 467 A.1. Regex versio 01 469 Rewrote Abstract and Into (MP) Introduced code 401 when changes are 470 not allowed Text edits and clarifications. 472 A.2. Regex version 00 474 Working group document same as 03, just track changed to standard 476 A.3. Version 03 478 Clarified based on comments and questions from early implementors 480 A.4. Version 02 482 Reflected comments on mailing lists 484 A.5. Version 01 486 This version adds a full REST definition this is based on suggestions 487 from Jakob Schlyter. 489 A.6. Version 00 491 First rough version 493 Authors' Addresses 495 Jacques Latour 496 CIRA 498 Email: jacques.latour@cira.ca 500 Olafur Gudmundsson 501 Cloudflare, Inc. 503 Email: olafur+ietf@cloudflare.com 505 Paul Wouters 506 Red Hat 508 Email: paul@nohats.ca 509 Matthew Pounsett 510 Rightside Group, Ltd. 512 Email: matt@conundrum.com