idnits 2.17.1 draft-ietf-regext-dnsoperator-to-rrr-protocol-04.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 (September 12, 2017) is 2411 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 (-14) exists of draft-ietf-dnsop-terminology-bis-06 -- 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: March 16, 2018 Cloudflare, Inc. 6 P. Wouters 7 Red Hat 8 M. Pounsett 9 Rightside Group, Ltd. 10 September 12, 2017 12 Third Party DNS operator to Registrars/Registries Protocol 13 draft-ietf-regext-dnsoperator-to-rrr-protocol-04 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 March 16, 2018. 57 Copyright Notice 59 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 95 8.2. Informative References . . . . . . . . . . . . . . . . . 12 96 Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 97 A.1. regext Version 04 . . . . . . . . . . . . . . . . . . . . 13 98 A.2. regext Version 03 . . . . . . . . . . . . . . . . . . . . 13 99 A.3. regext Version 02 . . . . . . . . . . . . . . . . . . . . 13 100 A.4. regext Version 01 . . . . . . . . . . . . . . . . . . . . 14 101 A.5. regext Version 00 . . . . . . . . . . . . . . . . . . . . 14 102 A.6. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 14 103 A.7. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 14 104 A.8. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 14 105 A.9. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 14 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 108 1. Introduction 110 After a domain has been registered, one of three parties will 111 maintain the DNS zone loaded on the "primary" DNS servers: the 112 Registrant, the Registrar, or a third party DNS operator. DNS 113 registration systems were originally designed around making 114 registrations easy and fast, however after registration the 115 complexity of making changes to the delegation differs for each of 116 these parties. The Registrar can make changes directly in the 117 Registry systems through some API (typically EPP [RFC5730]). The 118 Registrant is typically limited to using a web interface supplied by 119 the Registrar or Reseller. Typically, a third party DNS Operator 120 must to go through the Registrant to update any delegation 121 information. 123 Unless the responsible Registration Entity is scanning child zones 124 for CDS records in order to bootstrap or update DNSSEC, the operator 125 must contact and engage the Registrant in updating DS records for the 126 delegation. New information must be communicated to the Registrant, 127 who must submit that information to the Registrar. Typically this 128 involves cutting and pasting between email and a web interface, which 129 is error prone. Furthermore, involving Registrants in this way does 130 not scale for even moderately sized DNS operators. Tracking 131 thousands (or millions) of changes sent to customers, and following 132 up if those changes are not submitted to the Registrar, or are 133 submitted with errors, is itself expensive and error prone. 135 The current system does not work well, as there are many types of 136 failures that have been reported at all levels in the registration 137 model. The failures result in either the inability to use DNSSEC or 138 in validation failures that cause the domain to become unavailable to 139 users behind validating resolvers. 141 The goal of this document is to create a protocol for establishing a 142 secure chain of trust that involves parties not in the traditional 143 Registrant/Registrar/Registry (RRR) model, and to reduce the friction 144 in maintaining DNSSEC secured delegations in these cases. It 145 describes a REST-based [RFC6690] protocol which can be used to 146 establish DNSSEC initial trust (to enable or bootstrap DNSSEC), and 147 to trigger maintenance of DS records. 149 2. Notional Conventions 151 2.1. Definitions 153 For the purposes of this draft, a third-party DNS Operator is any DNS 154 Operator responsible for a zone, where the operator is neither the 155 Registrant nor the Registrar of record for the delegation. 157 Uses of "child" and "parent" refer to the relationship between DNS 158 zone operators (see [RFC7719] and [I-D.ietf-dnsop-terminology-bis]). 159 In this document, unless otherwise noted, the child is the third- 160 party DNS operator and the parent is the Registry. 162 Use of the term "Registration Entity" in this document may refer to 163 any party that engages directly in registration activities with the 164 Registrant. Typically this will be a Reseller or Registrar, but in 165 some cases, such as when a Registry directly sells registrations to 166 the public, may apply to the Registry. Even in cases where a 167 Registrar is involved, this term may still apply to a Registry if 168 that Registry normally accepts DS/DNSKEY updates directly from 169 Registrants. 171 The CDS and CDNSKEY DNS resource records, having substantially the 172 same function but for different record types, are used interchangably 173 in this document. Unless otherwise noted, any use of "CDS" or 174 "CDNSKEY" can be assumed to also refer to the other. 176 2.2. RFC2119 Keywords 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 3. Process Overview 184 3.1. Identifying the Registration Entity 186 As of publication of this document, there has never been a 187 standardized or widely deployed method for easily and scalably 188 identifying the Registration Entity for a particular registration. 190 At this time, WHOIS [RFC3912] is the only widely deployed protocol to 191 carry such information, but WHOIS responses are unstructured text, 192 and each implementor can lay out its text responses differently. In 193 addition, Registries may include referrals in this unstructured text 194 to the WHOIS interfaces of their Registrars, and those Registrar 195 WHOIS interface in turn have their own layouts. This presents a text 196 parsing problem which is infeasible to solve. 198 RDAP, the successor to WHOIS, described in [RFC7480], solves the 199 problems of unstructured responses, and a consistently implemented 200 referral system, however at this time RDAP has yet to be deployed at 201 most Registries. 203 With no current mechanism in place to scalably discover the Registrar 204 for a particular registration, the problem of automatic discovery of 205 the base URL of the API is considered out of scope of this document. 206 The authors recommend standardization of an RDAP extension to obtain 207 this information from the Registry. 209 3.2. Establishing a Chain of Trust 211 After signing the zone, the child DNS Operator needs to upload the DS 212 record(s) to the parent. The child can signal its desire to have 213 DNSSEC validation enabled by publishing one of the special DNS 214 records CDS and/or CDNSKEY as defined in [RFC7344] and [RFC8078]. 216 Registration Entities MAY regularly scan the child name servers of 217 unsecured delegations for CDS records in order to bootstrap DNSSEC, 218 and are advised to do so. At the time of publication, some ccTLD 219 Registries are already doing this. A Registration Entity that 220 regularly scans all child zones under its responsibility (both 221 secured and unsecured) for CDS will not require the API described in 222 this document. However, such a Registration Entity should follow the 223 guidelines discussed in Section 3.5 below when using CDS to bootstrap 224 DNSSEC on a previously unsecured delegation. 226 In the case where the Registration Entity is not normally scanning 227 child zones for CDS records, the Registration Entity SHOULD implement 228 the API from this document, allowing child operators to notify the 229 Registration Entity to begin such a scan. 231 Once the Registration Entity finds CDS records in a child zone it is 232 responsible for, or receives a signal via this API, it SHOULD start 233 acceptance processing as described below. 235 3.3. Maintaining the Chain of Trust 237 Once the secure chain of trust is established, the Registration 238 Entity SHOULD regularly scan the child zone for CDS record changes. 239 If the Registration Entity implements the protocol described in this 240 document, then it SHOULD also accept signals via this protocol to 241 immediately check the child zone for CDS records. 243 Server implementations of this protocol MAY include rate limiting to 244 protect their systems and the systems of child operators from abuse. 246 Each parent operator and Registration Entity is responsible for 247 developing, implementing, and communicating their DNSSEC maintenance 248 policies. 250 3.4. Acceptance Processing 252 The Registration Entity, upon receiving a signal or detecting through 253 polling that the child desires to have its delegation updated, SHOULD 254 run a series of tests to ensure that updating the parent zone will 255 not create or exacerbate any problems with the child zone. The basic 256 tests SHOULD include: 258 o checks that the child zone is is properly signed as per the 259 Registration Entity and parent DNSSEC policies 261 o if updating the DS record, a check to ensure the child CDS RRset 262 references a KSK which is present in the child DNSKEY RRset and 263 signs the CDS RRset 265 o ensuring all name servers in the apex NS RRset of the child zone 266 agree on the apex NS RRset and CDS RRset contents 268 The Registration Entity SHOULD NOT make any changes to the DS RRset 269 if the child name servers do not agree on the CDS content. 271 3.5. Bootstrapping DNSSEC 273 Registration Entities SHOULD require compliance with additional tests 274 in the case of establishing a new chain of trust. 276 o The Registration Entity SHOULD check that all child name servers 277 respond with a consistent CDS RRset for a number of queries over 278 an extended period of time. Any change in DS response or 279 inconsistency between child responses in that time might indicate 280 an attempted Man in the Middle (MITM) attack, and SHOULD reset the 281 test. This minimizes the possibility of an attacker spoofing 282 responses. An example of such a policy might be to scan all child 283 name servers in the delegation NS RRset every two hours for a 284 week. 286 o The Registration Entity SHOULD require all of the child name 287 servers in the delegation NS RRset to send the same response to a 288 CDS query whether sent over TCP or UDP. 290 o The Registration Entity MAY require the child zone to implement 291 zone delegation best practices as described in 292 [I-D.wallstrom-dnsop-dns-delegation-requirements]. 294 o The Registration Entity MAY require the child operator to prove 295 they can add data to the zone, for example by publishing a 296 particular token. See Section 4.2.2 below. 298 4. API Definition 300 This protocol is partially synchronous, meaning the server can elect 301 to hold connections open until operations have completed, or it can 302 return a status code indicating that it has received a request, and 303 close the connection. It is up to the child to monitor the parent 304 for completion of the operation, and issue possible follow-up calls 305 to the Registration Entity. 307 Clients may be denied access to change the DS records for domains 308 that are Registry Locked (HTTP Status code 401). Registry Lock is a 309 mechanism provided by certain Registries or Registrars that prevents 310 domain hijacking by ensuring no attributes of the domain are 311 changeable, and no transfer or deletion transactions can be processed 312 against the domain name without manual intervention. 314 4.1. Authentication 316 The API does not impose any unique server authentication 317 requirements. The server authentication provided by TLS fully 318 addresses the needs of this protocol. The API MUST be provided over 319 TLS-protected transport (e.g., HTTPS) or VPN. 321 Client authentication is considered out of scope of this document. 322 The publication of CDS records in the child zone is an indication 323 that the child operator intends to perform DS-record-updating 324 activities (add/delete) in the parent zone. Since this protocol is 325 simply a signal to the Registration Entity that they should examine 326 the child zone for such intentions, additional authentication of the 327 client making the request is considered unnecessary. 329 Registration Entities MAY implement their own policy to protect 330 access to the API, such as with IP white listing, client TLS 331 certificates, etc.. Registration Entities SHOULD take steps to 332 ensure that a lack of additional authentication does not open up a 333 denial of service mechanism against the systems of the Registration 334 Entity, the Registry, or the child operator. 336 4.2. RESTful Resources 338 In the following text, "{domain}" is the child zone to be operated 339 on. 341 4.2.1. CDS resource 343 Path: /domains/{domain}/cds 345 4.2.1.1. Establishing Initial Trust (Enabling DNSSEC) 347 4.2.1.1.1. Request 349 Syntax: POST /domains/{domain}/cds 351 Request that an initial set of DS records based on the CDS record in 352 the child zone be inserted into the Registry and the parent zone upon 353 the successful completion of the request. If there are multiple CDS 354 records in the CDS RRset, multiple DS records will be added. 356 The body of the POST SHOULD be empty, however server implementations 357 SHOULD NOT reject nonempty requests. 359 4.2.1.1.2. Response 361 o HTTP Status code 201 indicates a success. 363 o HTTP Status code 400 indicates a failure due to validation. 365 o HTTP Status code 401 indicates an unauthorized resource access. 367 o HTTP Status code 403 indicates a failure due to an invalid 368 challenge token. 370 o HTTP Status code 404 indicates the domain does not exist. 372 o HTTP Status code 409 indicates the delegation already has a DS 373 RRset. 375 o HTTP Status code 429 indicates the client has been rate-limited. 377 o HTTP Status code 500 indicates a failure due to unforeseeable 378 reasons. 380 This request is for setting up initial trust in the delegation. The 381 Registration Entity SHOULD return a status code 409 if it already has 382 a DS RRset for the child zone. 384 Upon receipt of a 403 response the child operator SHOULD issue a POST 385 for the "token" resource to fetch a challenge token to insert into 386 the zone. 388 4.2.1.2. Removing DS Records 390 4.2.1.2.1. Request 392 Syntax: DELETE /domains/{domain}/cds 394 Request that the Registration Entity check for a null CDS or CDNSKEY 395 record in the child zone, indicating a request that the entire DS 396 RRset be removed. This will make the delegation insecure. 398 4.2.1.2.2. Response 400 o HTTP Status code 200 indicates a success. 402 o HTTP Status code 400 indicates a failure due to validation. 404 o HTTP Status code 401 indicates an unauthorized resource access. 406 o HTTP Status code 404 indicates the domain does not exist. 408 o HTTP Status code 412 indicates the parent does not have a DS RRset 410 o HTTP Status code 429 indicates the client has been rate-limited. 412 o HTTP Status code 500 indicates a failure due to unforeseeable 413 reasons. 415 4.2.1.3. Modifying DS Records 417 4.2.1.3.1. Request 419 Syntax: PUT /domains/{domain}/cds 421 Request that the Registration Entity modify the DS RRset based on the 422 CDS/CDNSKEY available in the child zone. As a result of this request 423 the Registration Entity SHOULD add or delete DS or DNSKEY records as 424 indicated by the CDS/CDNSKEY RRset, but MUST NOT delete the entire DS 425 RRset. 427 4.2.1.3.2. Response 429 o HTTP Status code 200 indicates a success. 431 o HTTP Status code 400 indicates a failure due to validation. 433 o HTTP Status code 401 indicates an unauthorized resource access. 435 o HTTP Status code 404 indicates the domain does not exist. 437 o HTTP Status code 412 indicates the parent does not have a DS RRset 439 o HTTP Status code 429 indicates the client has been rate-limited. 441 o HTTP Status code 500 indicates a failure due to unforeseeable 442 reasons. 444 4.2.2. Token resource 446 Path: /domains/{domain}/token 448 4.2.2.1. Establish Initial Trust with Challenge 450 4.2.2.1.1. Request 452 Syntax: GET /domains/{domain}/token 454 The DNSSEC policy of the Registration Entity may require proof that 455 the DNS Operator is in control of the domain. The token API call 456 returns a random token to be included as a TXT record for the 457 _delegate.@ domain name (where @ is the apex of the child zone) prior 458 establishing the DNSSEC initial trust. This is an additional trust 459 control mechanism to establish the initial chain of trust. 461 Once the child operator has received a token, it SHOULD be inserted 462 in the zone and the operator SHOULD proceed with a POST of the cds 463 resource. 465 The Registration Entity MAY expire the token after a reasonable 466 period. The Registration Entity SHOULD document an explanation of 467 whether and when tokens are expired in their DNSSEC policy. 469 Note that the _delegate TXT record is publicly available and not a 470 secret token. 472 4.2.2.1.2. Response 474 o HTTP Status code 200 indicates a success. A token is included in 475 the body of the response, as a valid TXT record 477 o HTTP Status code 404 indicates the domain does not exist. 479 o HTTP Status code 500 indicates a failure due to unforeseeable 480 reasons. 482 4.3. Customized Error Messages 484 Registration Entities MAY provide a customized error message in the 485 response body in addition to the HTTP status code defined in the 486 previous section. This response MAY include an identifying number/ 487 string that can be used to track the request. 489 5. Security considerations 491 When zones are properly provisioned, and delegations follow standards 492 and best practices (e.g. 493 [I-D.wallstrom-dnsop-dns-delegation-requirements]), the Registration 494 Entity or Registry can trust the DNS information it receives from 495 multiple child name servers, over time, and/or over TCP to establish 496 the initial chain of trust. 498 In addition, the Registration Entity or Registry can require the DNS 499 Operator to prove they control the zone by requiring the child 500 operator to navigate additional hurdles, such as adding a challenge 501 token to the zone. 503 This protocol should increase the adoption of DNSSEC, enabling more 504 zones to become validated thus overall the security gain outweighs 505 the possible drawbacks. 507 Registrants and DNS Operators always have the option to establish the 508 chain of trust in band via the standard Registrant/Registrar/Registry 509 model. 511 6. IANA Actions 513 This document has no actions for IANA 515 7. Internationalization Considerations 517 This protocol is designed for machine to machine communications. 518 Clients and servers SHOULD use punycode [RFC3492] when operating on 519 internationalized domain names. 521 8. References 523 8.1. Normative References 525 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 526 for Internationalized Domain Names in Applications 527 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 528 . 530 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 531 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 532 . 534 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 535 DNSSEC Delegation Trust Maintenance", RFC 7344, 536 DOI 10.17487/RFC7344, September 2014, 537 . 539 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 540 the Parent via CDS/CDNSKEY", RFC 8078, 541 DOI 10.17487/RFC8078, March 2017, 542 . 544 8.2. Informative References 546 [I-D.ietf-dnsop-terminology-bis] 547 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 548 Terminology", draft-ietf-dnsop-terminology-bis-06 (work in 549 progress), July 2017. 551 [I-D.wallstrom-dnsop-dns-delegation-requirements] 552 Wallstrom, P. and J. Schlyter, "DNS Delegation 553 Requirements", draft-wallstrom-dnsop-dns-delegation- 554 requirements-03 (work in progress), October 2016. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, 558 DOI 10.17487/RFC2119, March 1997, 559 . 561 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 562 DOI 10.17487/RFC3912, September 2004, 563 . 565 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 566 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 567 . 569 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 570 Registration Data Access Protocol (RDAP)", RFC 7480, 571 DOI 10.17487/RFC7480, March 2015, 572 . 574 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 575 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 576 2015, . 578 Appendix A. Document History 580 A.1. regext Version 04 582 o changed uses of Registrar to Registration Entity and updated 583 definitions to improve clarity 585 o adding note about CDS/CDNSKEY interchangability in this document 587 o added advice to scan all delegations (including insecure 588 delegations) for CDS in order to bootstrap or update DNSSEC 590 o removed "Other Delegation Maintenance" section, since we decided a 591 while ago not to use this to update NS 593 A.2. regext Version 03 595 o simplify abstract 597 o move all justification text to Intro 599 o added HTTP response codes for rate limiting (429), missing DS 600 RRsets (412) 602 o expanded on Internationalization Considerations 604 o corrected informative/normative document references 606 o clarify parent/Registrar references in the draft 608 o general spelling/grammar/style cleanup 610 o removed references to NS and glue maintenance 612 o clarify content of POST body for 'cds' resource 614 o change verb for obtaining a 'token' to GET 616 o Updated reference to RFC8078 618 A.3. regext Version 02 620 o Clarified based on comments and questions from early implementors 621 (JL) 623 o Text edits and clarifications. 625 A.4. regext Version 01 627 o Rewrote Abstract and Into (MP) 629 o Introduced code 401 when changes are not allowed 631 o Text edits and clarifications. 633 A.5. regext Version 00 635 o Working group document same as 03, just track changed to standard 637 A.6. Version 03 639 o Clarified based on comments and questions from early implementors 641 A.7. Version 02 643 o Reflected comments on mailing lists 645 A.8. Version 01 647 o This version adds a full REST definition this is based on 648 suggestions from Jakob Schlyter. 650 A.9. Version 00 652 o First rough version 654 Authors' Addresses 656 Jacques Latour 657 CIRA 658 Ottawa, ON 660 Email: jacques.latour@cira.ca 662 Olafur Gudmundsson 663 Cloudflare, Inc. 664 San Francisco, CA 666 Email: olafur+ietf@cloudflare.com 667 Paul Wouters 668 Red Hat 669 Toronto, ON 671 Email: paul@nohats.ca 673 Matthew Pounsett 674 Rightside Group, Ltd. 675 Toronto, ON 677 Email: matt@conundrum.com