idnits 2.17.00 (12 Aug 2021) /tmp/idnits12516/draft-ietf-regext-dnsoperator-to-rrr-protocol-05.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 (May 4, 2018) is 1471 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: draft-ietf-dnsop-terminology-bis has been published as RFC 8499 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 1 error (**), 0 flaws (~~), 2 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: November 5, 2018 Cloudflare, Inc. 6 P. Wouters 7 Red Hat 8 M. Pounsett 9 Nimbus Operations Inc. 10 May 4, 2018 12 Third Party DNS operator to Registrars/Registries Protocol 13 draft-ietf-regext-dnsoperator-to-rrr-protocol-05 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 uses DNSSEC it necessary to make regular (sometimes 27 annual) changes to the delegation, updating DS record(s) in order to 28 track KSK rollover. Under the current model this is prone to delays 29 and errors, as the Registrant must participate in updates to DS 30 records. 32 This document describes a simple protocol that allows a third party 33 DNS operator to: establish the initial chain of trust (bootstrap 34 DNSSEC) for a delegation; update DS records for a delegation; and, 35 remove DS records from a secure delegation. The DNS operator may do 36 these things in a trusted manner, without involving the Registrant 37 for each operation. This same protocol can be used by Registrants to 38 maintain their own domains if they wish. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on November 5, 2018. 57 Copyright Notice 59 Copyright (c) 2018 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Notional Conventions . . . . . . . . . . . . . . . . . . . . 4 76 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 77 2.2. RFC2119 Keywords . . . . . . . . . . . . . . . . . . . . 4 78 3. Process Overview . . . . . . . . . . . . . . . . . . . . . . 4 79 3.1. Identifying the Registration Entity . . . . . . . . . . . 4 80 3.2. Establishing a Chain of Trust . . . . . . . . . . . . . . 5 81 3.3. Maintaining the Chain of Trust . . . . . . . . . . . . . 5 82 3.4. Acceptance Processing . . . . . . . . . . . . . . . . . . 6 83 3.5. Bootstrapping DNSSEC . . . . . . . . . . . . . . . . . . 6 84 4. API Definition . . . . . . . . . . . . . . . . . . . . . . . 7 85 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7 86 4.2. RESTful Resources . . . . . . . . . . . . . . . . . . . . 8 87 4.2.1. CDS resource . . . . . . . . . . . . . . . . . . . . 8 88 4.2.2. Token resource . . . . . . . . . . . . . . . . . . . 10 89 4.3. Customized Error Messages . . . . . . . . . . . . . . . . 11 90 5. Security considerations . . . . . . . . . . . . . . . . . . . 11 91 6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 11 92 7. Internationalization Considerations . . . . . . . . . . . . . 11 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 95 8.2. Informative References . . . . . . . . . . . . . . . . . 12 96 Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 97 A.1. regext Version 05 . . . . . . . . . . . . . . . . . . . . 13 98 A.2. regext Version 04 . . . . . . . . . . . . . . . . . . . . 13 99 A.3. regext Version 03 . . . . . . . . . . . . . . . . . . . . 13 100 A.4. regext Version 02 . . . . . . . . . . . . . . . . . . . . 14 101 A.5. regext Version 01 . . . . . . . . . . . . . . . . . . . . 14 102 A.6. regext Version 00 . . . . . . . . . . . . . . . . . . . . 14 103 A.7. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 14 104 A.8. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 14 105 A.9. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 14 106 A.10. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 14 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 109 1. Introduction 111 After a domain has been registered, one of three parties will 112 maintain the DNS zone loaded on the "primary" DNS servers: the 113 Registrant, the Registrar, or a third party DNS operator. DNS 114 registration systems were originally designed around making 115 registrations easy and fast, however after registration the 116 complexity of making changes to the delegation differs for each of 117 these parties. The Registrar can make changes directly in the 118 Registry systems through some API (typically EPP [RFC5730]). The 119 Registrant is typically limited to using a web interface supplied by 120 the Registrar or Reseller. Typically, a third party DNS Operator 121 must to go through the Registrant to update any delegation 122 information. 124 Unless the responsible Registration Entity is scanning child zones 125 for CDS records in order to bootstrap or update DNSSEC, the operator 126 must contact and engage the Registrant in updating DS records for the 127 delegation. New information must be communicated to the Registrant, 128 who must submit that information to the Registrar. Typically this 129 involves cutting and pasting between email and a web interface, which 130 is error prone. Furthermore, involving Registrants in this way does 131 not scale for even moderately sized DNS operators. Tracking 132 thousands (or millions) of changes sent to customers, and following 133 up if those changes are not submitted to the Registrar, or are 134 submitted with errors, is itself expensive and error prone. 136 The current system does not work well, as there are many types of 137 failures that have been reported at all levels in the registration 138 model. The failures result in either the inability to use DNSSEC or 139 in validation failures that cause the domain to become unavailable to 140 users behind validating resolvers. 142 The goal of this document is to create a protocol for establishing a 143 secure chain of trust that involves parties not in the traditional 144 Registrant/Registrar/Registry (RRR) model, and to reduce the friction 145 in maintaining DNSSEC secured delegations in these cases. It 146 describes a REST-based [RFC6690] protocol which can be used to 147 establish DNSSEC initial trust (to enable or bootstrap DNSSEC), and 148 to trigger maintenance of DS records. 150 2. Notional Conventions 152 2.1. Definitions 154 For the purposes of this draft, a third-party DNS Operator is any DNS 155 Operator responsible for a zone, where the operator is neither the 156 Registrant nor the Registrar of record for the delegation. 158 Uses of "child" and "parent" refer to the relationship between DNS 159 zone operators (see [RFC7719] and [I-D.ietf-dnsop-terminology-bis]). 160 In this document, unless otherwise noted, the child is the third- 161 party DNS operator and the parent is the Registry. 163 Use of the term "Registration Entity" in this document may refer to 164 any party that engages directly in registration activities with the 165 Registrant. Typically this will be a Reseller or Registrar, but in 166 some cases, such as when a Registry directly sells registrations to 167 the public, may apply to the Registry. Even in cases where a 168 Registrar is involved, this term may still apply to a Registry if 169 that Registry normally accepts DS/DNSKEY updates directly from 170 Registrants. 172 The CDS and CDNSKEY DNS resource records, having substantially the 173 same function but for different record types, are used interchangably 174 in this document. Unless otherwise noted, any use of "CDS" or 175 "CDNSKEY" can be assumed to also refer to the other. 177 2.2. RFC2119 Keywords 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [RFC2119]. 183 3. Process Overview 185 3.1. Identifying the Registration Entity 187 As of publication of this document, there has never been a 188 standardized or widely deployed method for easily and scalably 189 identifying the Registration Entity for a particular registration. 191 At this time, WHOIS [RFC3912] is the only widely deployed protocol to 192 carry such information, but WHOIS responses are unstructured text, 193 and each implementor can lay out its text responses differently. In 194 addition, Registries may include referrals in this unstructured text 195 to the WHOIS interfaces of their Registrars, and those Registrar 196 WHOIS interface in turn have their own layouts. This presents a text 197 parsing problem which is infeasible to solve. 199 RDAP, the successor to WHOIS, described in [RFC7480], solves the 200 problems of unstructured responses, and a consistently implemented 201 referral system, however at this time RDAP has yet to be deployed at 202 most Registries. 204 With no current mechanism in place to scalably discover the Registrar 205 for a particular registration, the problem of automatic discovery of 206 the base URL of the API is considered out of scope of this document. 207 The authors recommend standardization of an RDAP extension to obtain 208 this information from the Registry. 210 3.2. Establishing a Chain of Trust 212 After signing the zone, the child DNS Operator needs to upload the DS 213 record(s) to the parent. The child can signal its desire to have 214 DNSSEC validation enabled by publishing one of the special DNS 215 records CDS and/or CDNSKEY as defined in [RFC7344] and [RFC8078]. 217 Registration Entities MAY regularly scan the child name servers of 218 unsecured delegations for CDS records in order to bootstrap DNSSEC, 219 and are advised to do so. At the time of publication, some ccTLD 220 Registries are already doing this. A Registration Entity that 221 regularly scans all child zones under its responsibility (both 222 secured and unsecured) for CDS will not require the API described in 223 this document. However, such a Registration Entity should follow the 224 guidelines discussed in Section 3.5 below when using CDS to bootstrap 225 DNSSEC on a previously unsecured delegation. 227 In the case where the Registration Entity is not normally scanning 228 child zones for CDS records, the Registration Entity SHOULD implement 229 the API from this document, allowing child operators to notify the 230 Registration Entity to begin such a scan. 232 Once the Registration Entity finds CDS records in a child zone it is 233 responsible for, or receives a signal via this API, it SHOULD start 234 acceptance processing as described below. 236 3.3. Maintaining the Chain of Trust 238 Once the secure chain of trust is established, the Registration 239 Entity SHOULD regularly scan the child zone for CDS record changes. 240 If the Registration Entity implements the protocol described in this 241 document, then it SHOULD also accept signals via this protocol to 242 immediately check the child zone for CDS records. 244 Server implementations of this protocol MAY include rate limiting to 245 protect their systems and the systems of child operators from abuse. 247 Each parent operator and Registration Entity is responsible for 248 developing, implementing, and communicating their DNSSEC maintenance 249 policies. 251 3.4. Acceptance Processing 253 The Registration Entity, upon receiving a signal or detecting through 254 polling that the child desires to have its delegation updated, SHOULD 255 run a series of tests to ensure that updating the parent zone will 256 not create or exacerbate any problems with the child zone. The basic 257 tests SHOULD include: 259 o checks that the child zone is is properly signed as per the 260 Registration Entity and parent DNSSEC policies 262 o if updating the DS record, a check to ensure the child CDS RRset 263 references a KSK which is present in the child DNSKEY RRset and 264 signs the CDS RRset 266 o ensuring all name servers in the apex NS RRset of the child zone 267 agree on the apex NS RRset and CDS RRset contents 269 The Registration Entity SHOULD NOT make any changes to the DS RRset 270 if the child name servers do not agree on the CDS content. 272 3.5. Bootstrapping DNSSEC 274 Registration Entities SHOULD require compliance with additional tests 275 in the case of establishing a new chain of trust. 277 o The Registration Entity SHOULD check that all child name servers 278 respond with a consistent CDS RRset for a number of queries over 279 an extended period of time. Any change in DS response or 280 inconsistency between child responses in that time might indicate 281 an attempted Man in the Middle (MITM) attack, and SHOULD reset the 282 test. This minimizes the possibility of an attacker spoofing 283 responses. An example of such a policy might be to scan all child 284 name servers in the delegation NS RRset every two hours for a 285 week. 287 o The Registration Entity SHOULD require all of the child name 288 servers in the delegation NS RRset to send the same response to a 289 CDS query whether sent over TCP or UDP. 291 o The Registration Entity MAY require the child zone to implement 292 zone delegation best practices as described in 293 [I-D.wallstrom-dnsop-dns-delegation-requirements]. 295 o The Registration Entity MAY require the child operator to prove 296 they can add data to the zone, for example by publishing a 297 particular token. See Section 4.2.2 below. 299 4. API Definition 301 This protocol is partially synchronous, meaning the server can elect 302 to hold connections open until operations have completed, or it can 303 return a status code indicating that it has received a request, and 304 close the connection. It is up to the child to monitor the parent 305 for completion of the operation, and issue possible follow-up calls 306 to the Registration Entity. 308 Clients may be denied access to change the DS records for domains 309 that are Registry Locked (HTTP Status code 401). Registry Lock is a 310 mechanism provided by certain Registries or Registrars that prevents 311 domain hijacking by ensuring no attributes of the domain are 312 changeable, and no transfer or deletion transactions can be processed 313 against the domain name without manual intervention. 315 4.1. Authentication 317 The API does not impose any unique server authentication 318 requirements. The server authentication provided by TLS fully 319 addresses the needs of this protocol. The API MUST be provided over 320 TLS-protected transport (e.g., HTTPS) or VPN. 322 Client authentication is considered out of scope of this document. 323 The publication of CDS records in the child zone is an indication 324 that the child operator intends to perform DS-record-updating 325 activities (add/delete) in the parent zone. Since this protocol is 326 simply a signal to the Registration Entity that they should examine 327 the child zone for such intentions, additional authentication of the 328 client making the request is considered unnecessary. 330 Registration Entities MAY implement their own policy to protect 331 access to the API, such as with IP white listing, client TLS 332 certificates, etc.. Registration Entities SHOULD take steps to 333 ensure that a lack of additional authentication does not open up a 334 denial of service mechanism against the systems of the Registration 335 Entity, the Registry, or the child operator. 337 4.2. RESTful Resources 339 In the following text, "{domain}" is the child zone to be operated 340 on. 342 4.2.1. CDS resource 344 Path: /domains/{domain}/cds 346 4.2.1.1. Establishing Initial Trust (Enabling DNSSEC) 348 4.2.1.1.1. Request 350 Syntax: POST /domains/{domain}/cds 352 Request that an initial set of DS records based on the CDS record in 353 the child zone be inserted into the Registry and the parent zone upon 354 the successful completion of the request. If there are multiple CDS 355 records in the CDS RRset, multiple DS records will be added. 357 The body of the POST SHOULD be empty, however server implementations 358 SHOULD NOT reject nonempty requests. 360 4.2.1.1.2. Response 362 o HTTP Status code 201 indicates a success. 364 o HTTP Status code 400 indicates a failure due to validation. 366 o HTTP Status code 401 indicates an unauthorized resource access. 368 o HTTP Status code 403 indicates a failure due to an invalid 369 challenge token. 371 o HTTP Status code 404 indicates the domain does not exist. 373 o HTTP Status code 409 indicates the delegation already has a DS 374 RRset. 376 o HTTP Status code 429 indicates the client has been rate-limited. 378 o HTTP Status code 500 indicates a failure due to unforeseeable 379 reasons. 381 This request is for setting up initial trust in the delegation. The 382 Registration Entity SHOULD return a status code 409 if it already has 383 a DS RRset for the child zone. 385 Upon receipt of a 403 response the child operator SHOULD issue a POST 386 for the "token" resource to fetch a challenge token to insert into 387 the zone. 389 4.2.1.2. Removing DS Records 391 4.2.1.2.1. Request 393 Syntax: DELETE /domains/{domain}/cds 395 Request that the Registration Entity check for a null CDS or CDNSKEY 396 record in the child zone, indicating a request that the entire DS 397 RRset be removed. This will make the delegation insecure. 399 4.2.1.2.2. Response 401 o HTTP Status code 200 indicates a success. 403 o HTTP Status code 400 indicates a failure due to validation. 405 o HTTP Status code 401 indicates an unauthorized resource access. 407 o HTTP Status code 404 indicates the domain does not exist. 409 o HTTP Status code 412 indicates the parent does not have a DS RRset 411 o HTTP Status code 429 indicates the client has been rate-limited. 413 o HTTP Status code 500 indicates a failure due to unforeseeable 414 reasons. 416 4.2.1.3. Modifying DS Records 418 4.2.1.3.1. Request 420 Syntax: PUT /domains/{domain}/cds 422 Request that the Registration Entity modify the DS RRset based on the 423 CDS/CDNSKEY available in the child zone. As a result of this request 424 the Registration Entity SHOULD add or delete DS or DNSKEY records as 425 indicated by the CDS/CDNSKEY RRset, but MUST NOT delete the entire DS 426 RRset. 428 4.2.1.3.2. Response 430 o HTTP Status code 200 indicates a success. 432 o HTTP Status code 400 indicates a failure due to validation. 434 o HTTP Status code 401 indicates an unauthorized resource access. 436 o HTTP Status code 404 indicates the domain does not exist. 438 o HTTP Status code 412 indicates the parent does not have a DS RRset 440 o HTTP Status code 429 indicates the client has been rate-limited. 442 o HTTP Status code 500 indicates a failure due to unforeseeable 443 reasons. 445 4.2.2. Token resource 447 Path: /domains/{domain}/token 449 4.2.2.1. Establish Initial Trust with Challenge 451 4.2.2.1.1. Request 453 Syntax: GET /domains/{domain}/token 455 The DNSSEC policy of the Registration Entity may require proof that 456 the DNS Operator is in control of the domain. The token API call 457 returns a random token to be included as a TXT record for the 458 _delegate.@ domain name (where @ is the apex of the child zone) prior 459 establishing the DNSSEC initial trust. This is an additional trust 460 control mechanism to establish the initial chain of trust. 462 Once the child operator has received a token, it SHOULD be inserted 463 in the zone and the operator SHOULD proceed with a POST of the cds 464 resource. 466 The Registration Entity MAY expire the token after a reasonable 467 period. The Registration Entity SHOULD document an explanation of 468 whether and when tokens are expired in their DNSSEC policy. 470 Note that the _delegate TXT record is publicly available and not a 471 secret token. 473 4.2.2.1.2. Response 475 o HTTP Status code 200 indicates a success. A token is included in 476 the body of the response, as a valid TXT record 478 o HTTP Status code 404 indicates the domain does not exist. 480 o HTTP Status code 500 indicates a failure due to unforeseeable 481 reasons. 483 4.3. Customized Error Messages 485 Registration Entities MAY provide a customized error message in the 486 response body in addition to the HTTP status code defined in the 487 previous section. This response MAY include an identifying number/ 488 string that can be used to track the request. 490 5. Security considerations 492 When zones are properly provisioned, and delegations follow standards 493 and best practices (e.g. 494 [I-D.wallstrom-dnsop-dns-delegation-requirements]), the Registration 495 Entity or Registry can trust the DNS information it receives from 496 multiple child name servers, over time, and/or over TCP to establish 497 the initial chain of trust. 499 In addition, the Registration Entity or Registry can require the DNS 500 Operator to prove they control the zone by requiring the child 501 operator to navigate additional hurdles, such as adding a challenge 502 token to the zone. 504 This protocol should increase the adoption of DNSSEC, enabling more 505 zones to become validated thus overall the security gain outweighs 506 the possible drawbacks. 508 Registrants and DNS Operators always have the option to establish the 509 chain of trust in band via the standard Registrant/Registrar/Registry 510 model. 512 6. IANA Actions 514 This document has no actions for IANA 516 7. Internationalization Considerations 518 This protocol is designed for machine to machine communications. 519 Clients and servers SHOULD use punycode [RFC3492] when operating on 520 internationalized domain names. 522 8. References 524 8.1. Normative References 526 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 527 for Internationalized Domain Names in Applications 528 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 529 . 531 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 532 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 533 . 535 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 536 DNSSEC Delegation Trust Maintenance", RFC 7344, 537 DOI 10.17487/RFC7344, September 2014, 538 . 540 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 541 the Parent via CDS/CDNSKEY", RFC 8078, 542 DOI 10.17487/RFC8078, March 2017, 543 . 545 8.2. Informative References 547 [I-D.ietf-dnsop-terminology-bis] 548 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 549 Terminology", draft-ietf-dnsop-terminology-bis-10 (work in 550 progress), April 2018. 552 [I-D.wallstrom-dnsop-dns-delegation-requirements] 553 Wallstrom, P. and J. Schlyter, "DNS Delegation 554 Requirements", draft-wallstrom-dnsop-dns-delegation- 555 requirements-03 (work in progress), October 2016. 557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 558 Requirement Levels", BCP 14, RFC 2119, 559 DOI 10.17487/RFC2119, March 1997, 560 . 562 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 563 DOI 10.17487/RFC3912, September 2004, 564 . 566 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 567 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 568 . 570 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 571 Registration Data Access Protocol (RDAP)", RFC 7480, 572 DOI 10.17487/RFC7480, March 2015, 573 . 575 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 576 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 577 2015, . 579 Appendix A. Document History 581 A.1. regext Version 05 583 o new version to keep the draft alive 585 o updating author organization 587 A.2. regext Version 04 589 o changed uses of Registrar to Registration Entity and updated 590 definitions to improve clarity 592 o adding note about CDS/CDNSKEY interchangability in this document 594 o added advice to scan all delegations (including insecure 595 delegations) for CDS in order to bootstrap or update DNSSEC 597 o removed "Other Delegation Maintenance" section, since we decided a 598 while ago not to use this to update NS 600 A.3. regext Version 03 602 o simplify abstract 604 o move all justification text to Intro 606 o added HTTP response codes for rate limiting (429), missing DS 607 RRsets (412) 609 o expanded on Internationalization Considerations 611 o corrected informative/normative document references 613 o clarify parent/Registrar references in the draft 615 o general spelling/grammar/style cleanup 617 o removed references to NS and glue maintenance 618 o clarify content of POST body for 'cds' resource 620 o change verb for obtaining a 'token' to GET 622 o Updated reference to RFC8078 624 A.4. regext Version 02 626 o Clarified based on comments and questions from early implementors 627 (JL) 629 o Text edits and clarifications. 631 A.5. regext Version 01 633 o Rewrote Abstract and Into (MP) 635 o Introduced code 401 when changes are not allowed 637 o Text edits and clarifications. 639 A.6. regext Version 00 641 o Working group document same as 03, just track changed to standard 643 A.7. Version 03 645 o Clarified based on comments and questions from early implementors 647 A.8. Version 02 649 o Reflected comments on mailing lists 651 A.9. Version 01 653 o This version adds a full REST definition this is based on 654 suggestions from Jakob Schlyter. 656 A.10. Version 00 658 o First rough version 660 Authors' Addresses 661 Jacques Latour 662 CIRA 663 Ottawa, ON 665 Email: jacques.latour@cira.ca 667 Olafur Gudmundsson 668 Cloudflare, Inc. 669 San Francisco, CA 671 Email: olafur+ietf@cloudflare.com 673 Paul Wouters 674 Red Hat 675 Toronto, ON 677 Email: paul@nohats.ca 679 Matthew Pounsett 680 Nimbus Operations Inc. 681 Toronto, ON 683 Email: matt@conundrum.com