--- 1/draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt 2017-09-12 19:13:09.514551028 -0700 +++ 2/draft-ietf-regext-dnsoperator-to-rrr-protocol-04.txt 2017-09-12 19:13:09.546551799 -0700 @@ -1,137 +1,143 @@ regext J. Latour Internet-Draft CIRA Intended status: Standards Track O. Gudmundsson -Expires: September 13, 2017 Cloudflare, Inc. +Expires: March 16, 2018 Cloudflare, Inc. P. Wouters Red Hat M. Pounsett Rightside Group, Ltd. - March 12, 2017 + September 12, 2017 Third Party DNS operator to Registrars/Registries Protocol - draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt + draft-ietf-regext-dnsoperator-to-rrr-protocol-04 Abstract There are several problems that arise in the standard Registrant/Registrar/Registry model when the operator of a zone is neither the Registrant nor the Registrar for the delegation. Historically the issues have been minor, and limited to difficulty guiding the Registrant through the initial changes to the NS records for the delegation. As this is usually a one time activity when the operator first takes charge of the zone it has not been treated as a serious issue. When the domain uses DNSSEC it necessary to make regular (sometimes annual) changes to the delegation, updating DS record(s) in order to track KSK rollover. Under the current model this is prone to delays and errors, as the Registrant must participate in updates to DS records. This document describes a simple protocol that allows a third party - DNS operator to update DS records for a delegation, in a trusted - manner, without involving the Registrant for each operation. This - same protocol can be used by Registrants. + DNS operator to: establish the initial chain of trust (bootstrap + DNSSEC) for a delegation; update DS records for a delegation; and, + remove DS records from a secure delegation. The DNS operator may do + these things in a trusted manner, without involving the Registrant + for each operation. This same protocol can be used by Registrants to + maintain their own domains if they wish. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 13, 2017. + This Internet-Draft will expire on March 16, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notional Conventions . . . . . . . . . . . . . . . . . . . . 4 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. RFC2119 Keywords . . . . . . . . . . . . . . . . . . . . 4 3. Process Overview . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Identifying the Registrar . . . . . . . . . . . . . . . . 4 + 3.1. Identifying the Registration Entity . . . . . . . . . . . 4 3.2. Establishing a Chain of Trust . . . . . . . . . . . . . . 5 3.3. Maintaining the Chain of Trust . . . . . . . . . . . . . 5 - 3.4. Other Delegation Maintenance . . . . . . . . . . . . . . 5 - 3.5. Acceptance Processing . . . . . . . . . . . . . . . . . . 5 - 4. API Definition . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.4. Acceptance Processing . . . . . . . . . . . . . . . . . . 6 + 3.5. Bootstrapping DNSSEC . . . . . . . . . . . . . . . . . . 6 + 4. API Definition . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7 - 4.2. RESTful Resources . . . . . . . . . . . . . . . . . . . . 7 - 4.2.1. CDS resource . . . . . . . . . . . . . . . . . . . . 7 - 4.2.2. Token resource . . . . . . . . . . . . . . . . . . . 9 - 4.3. Customized Error Messages . . . . . . . . . . . . . . . . 10 - 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 + 4.2. RESTful Resources . . . . . . . . . . . . . . . . . . . . 8 + 4.2.1. CDS resource . . . . . . . . . . . . . . . . . . . . 8 + 4.2.2. Token resource . . . . . . . . . . . . . . . . . . . 10 + 4.3. Customized Error Messages . . . . . . . . . . . . . . . . 11 + 5. Security considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Internationalization Considerations . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 8.2. Informative References . . . . . . . . . . . . . . . . . 11 - Appendix A. Document History . . . . . . . . . . . . . . . . . . 12 - A.1. regext Version 03 . . . . . . . . . . . . . . . . . . . . 12 - A.2. regext Version 02 . . . . . . . . . . . . . . . . . . . . 13 - A.3. regext Version 01 . . . . . . . . . . . . . . . . . . . . 13 - A.4. regext Version 00 . . . . . . . . . . . . . . . . . . . . 13 - A.5. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 13 - A.6. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 13 - A.7. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 13 - A.8. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 + A.1. regext Version 04 . . . . . . . . . . . . . . . . . . . . 13 + A.2. regext Version 03 . . . . . . . . . . . . . . . . . . . . 13 + A.3. regext Version 02 . . . . . . . . . . . . . . . . . . . . 13 + A.4. regext Version 01 . . . . . . . . . . . . . . . . . . . . 14 + A.5. regext Version 00 . . . . . . . . . . . . . . . . . . . . 14 + A.6. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 14 + A.7. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 14 + A.8. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 14 + A.9. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction After a domain has been registered, one of three parties will maintain the DNS zone loaded on the "primary" DNS servers: the Registrant, the Registrar, or a third party DNS operator. DNS registration systems were originally designed around making registrations easy and fast, however after registration the complexity of making changes to the delegation differs for each of these parties. The Registrar can make changes directly in the Registry systems through some API (typically EPP [RFC5730]). The Registrant is typically limited to using a web interface supplied by - the Registrar. A third party DNS Operator must to go through the - Registrant to update any delegation information. + the Registrar or Reseller. Typically, a third party DNS Operator + must to go through the Registrant to update any delegation + information. - In this last case, the operator must contact and engage the - Registrant in updating NS and DS records for the delegation. New - information must be communicated to the Registrant, who must submit - that information to the Registrar. Typically this involves cutting - and pasting between email and a web interface, which is error prone. - Furthermore, involving Registrants in this way does not scale for - even moderately sized DNS operators. Tracking thousands (or - millions) of changes sent to customers, and following up if those - changes are not submitted to the Registrar, or are submitted with - errors, is itself expensive and error prone. + Unless the responsible Registration Entity is scanning child zones + for CDS records in order to bootstrap or update DNSSEC, the operator + must contact and engage the Registrant in updating DS records for the + delegation. New information must be communicated to the Registrant, + who must submit that information to the Registrar. Typically this + involves cutting and pasting between email and a web interface, which + is error prone. Furthermore, involving Registrants in this way does + not scale for even moderately sized DNS operators. Tracking + thousands (or millions) of changes sent to customers, and following + up if those changes are not submitted to the Registrar, or are + submitted with errors, is itself expensive and error prone. The current system does not work well, as there are many types of failures that have been reported at all levels in the registration model. The failures result in either the inability to use DNSSEC or in validation failures that cause the domain to become unavailable to users behind validating resolvers. The goal of this document is to create a protocol for establishing a secure chain of trust that involves parties not in the traditional Registrant/Registrar/Registry (RRR) model, and to reduce the friction @@ -142,175 +148,197 @@ 2. Notional Conventions 2.1. Definitions For the purposes of this draft, a third-party DNS Operator is any DNS Operator responsible for a zone, where the operator is neither the Registrant nor the Registrar of record for the delegation. Uses of "child" and "parent" refer to the relationship between DNS - zone operators. In this document, unless otherwise noted, the child - is the third-party DNS operator and the parent is the Registry. + zone operators (see [RFC7719] and [I-D.ietf-dnsop-terminology-bis]). + In this document, unless otherwise noted, the child is the third- + party DNS operator and the parent is the Registry. - Uses of the words "Registrar" or "Registration Entity" in this - document may also be applied to Resellers or to Registries that - engage in registration activities directly with Registrants. Unless - otherwise noted, they are used to refer to the entity which has a - direct business relationship with the Registrant. + Use of the term "Registration Entity" in this document may refer to + any party that engages directly in registration activities with the + Registrant. Typically this will be a Reseller or Registrar, but in + some cases, such as when a Registry directly sells registrations to + the public, may apply to the Registry. Even in cases where a + Registrar is involved, this term may still apply to a Registry if + that Registry normally accepts DS/DNSKEY updates directly from + Registrants. + + The CDS and CDNSKEY DNS resource records, having substantially the + same function but for different record types, are used interchangably + in this document. Unless otherwise noted, any use of "CDS" or + "CDNSKEY" can be assumed to also refer to the other. 2.2. RFC2119 Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Process Overview -3.1. Identifying the Registrar +3.1. Identifying the Registration Entity As of publication of this document, there has never been a standardized or widely deployed method for easily and scalably - identifying the Registar for a particular registration. + identifying the Registration Entity for a particular registration. At this time, WHOIS [RFC3912] is the only widely deployed protocol to carry such information, but WHOIS responses are unstructured text, and each implementor can lay out its text responses differently. In addition, Registries may include referrals in this unstructured text to the WHOIS interfaces of their Registrars, and those Registrar WHOIS interface in turn have their own layouts. This presents a text parsing problem which is infeasible to solve. RDAP, the successor to WHOIS, described in [RFC7480], solves the problems of unstructured responses, and a consistently implemented referral system, however at this time RDAP has yet to be deployed at most Registries. - With no current mechanism in place to scalably discover the Registar + With no current mechanism in place to scalably discover the Registrar for a particular registration, the problem of automatic discovery of the base URL of the API is considered out of scope of this document. - The authors recommend standardization of an RDAP extension to obtain this information from the Registry. 3.2. Establishing a Chain of Trust - After signing the zone, the child operator needs to upload the DS + After signing the zone, the child DNS Operator needs to upload the DS record(s) to the parent. The child can signal its desire to have DNSSEC validation enabled by publishing one of the special DNS records CDS and/or CDNSKEY as defined in [RFC7344] and [RFC8078]. - [RFC Editor: The above I-D reference should be replaced with the - correct RFC number upon publication.] + Registration Entities MAY regularly scan the child name servers of + unsecured delegations for CDS records in order to bootstrap DNSSEC, + and are advised to do so. At the time of publication, some ccTLD + Registries are already doing this. A Registration Entity that + regularly scans all child zones under its responsibility (both + secured and unsecured) for CDS will not require the API described in + this document. However, such a Registration Entity should follow the + guidelines discussed in Section 3.5 below when using CDS to bootstrap + DNSSEC on a previously unsecured delegation. - In the case of an insecure delegation, the Registrar will normally - not be scanning the child zone for CDS/CDNSKEY records. The child - operator can use this protocol to notify the Registrar to begin such - a scan. + In the case where the Registration Entity is not normally scanning + child zones for CDS records, the Registration Entity SHOULD implement + the API from this document, allowing child operators to notify the + Registration Entity to begin such a scan. - Once the Registrar sees these records it SHOULD start acceptance - processing. + Once the Registration Entity finds CDS records in a child zone it is + responsible for, or receives a signal via this API, it SHOULD start + acceptance processing as described below. 3.3. Maintaining the Chain of Trust - One the secure chain of trust is established, the Registrar SHOULD - regularly check the child zone for CDS/CDNSKEY record changes. The - Registrar SHOULD also accept signals via this protocol to immediately - check the child zone for CDS/CDNSKEY records. + Once the secure chain of trust is established, the Registration + Entity SHOULD regularly scan the child zone for CDS record changes. + If the Registration Entity implements the protocol described in this + document, then it SHOULD also accept signals via this protocol to + immediately check the child zone for CDS records. Server implementations of this protocol MAY include rate limiting to protect their systems and the systems of child operators from abuse. - Each parent operator and Registrar is responsible for developing, - implementing, and communicating their DNSSEC maintenance policies. - -3.4. Other Delegation Maintenance - - [ Not yet defined ] + Each parent operator and Registration Entity is responsible for + developing, implementing, and communicating their DNSSEC maintenance + policies. -3.5. Acceptance Processing +3.4. Acceptance Processing - The Registrar, upon receiving a signal or detecting through polling - that the child desires to have its delegation updated, SHOULD run a - series of tests to ensure that updating the parent zone will not - create or exacerbate any problems with the child zone. The basic + The Registration Entity, upon receiving a signal or detecting through + polling that the child desires to have its delegation updated, SHOULD + run a series of tests to ensure that updating the parent zone will + not create or exacerbate any problems with the child zone. The basic tests SHOULD include: - o checking that the child zone is is properly signed as per the - Registrar and parent DNSSEC policy + o checks that the child zone is is properly signed as per the + Registration Entity and parent DNSSEC policies - o if updating the DS record, checking that the child CDS RRset + o if updating the DS record, a check to ensure the child CDS RRset references a KSK which is present in the child DNSKEY RRset and signs the CDS RRset o ensuring all name servers in the apex NS RRset of the child zone agree on the apex NS RRset and CDS RRset contents - The Registrar SHOULD NOT make any changes to the DS RRset if the - child name servers do not agree on the CDS/CDNSKEY content. + The Registration Entity SHOULD NOT make any changes to the DS RRset + if the child name servers do not agree on the CDS content. - [NOTE: Do we need a new section in the DPS for the CDS management - policy [RFC6841]?] +3.5. Bootstrapping DNSSEC - Registrars MAY require compliance with additional tests, particularly - in the case of establishing a new chain of trust, such as: + Registration Entities SHOULD require compliance with additional tests + in the case of establishing a new chain of trust. - o checking that all child name servers to respond with a consistent - CDS/CDNSKEY RRset for a number of queries over an extended period - of time to minimise the possibility of an attacker spoofing - responses + o The Registration Entity SHOULD check that all child name servers + respond with a consistent CDS RRset for a number of queries over + an extended period of time. Any change in DS response or + inconsistency between child responses in that time might indicate + an attempted Man in the Middle (MITM) attack, and SHOULD reset the + test. This minimizes the possibility of an attacker spoofing + responses. An example of such a policy might be to scan all child + name servers in the delegation NS RRset every two hours for a + week. - o requiring the child name servers to respond with identical CDS/ - CDNSKEY RRsets over TCP + o The Registration Entity SHOULD require all of the child name + servers in the delegation NS RRset to send the same response to a + CDS query whether sent over TCP or UDP. - o ensuring zone delegation best practices (for examples, see - [I-D.wallstrom-dnsop-dns-delegation-requirements] + o The Registration Entity MAY require the child zone to implement + zone delegation best practices as described in + [I-D.wallstrom-dnsop-dns-delegation-requirements]. - o requiring the child operator to prove they can add data to the - zone (for example, by publishing a particular token) + o The Registration Entity MAY require the child operator to prove + they can add data to the zone, for example by publishing a + particular token. See Section 4.2.2 below. 4. API Definition This protocol is partially synchronous, meaning the server can elect to hold connections open until operations have completed, or it can return a status code indicating that it has received a request, and close the connection. It is up to the child to monitor the parent for completion of the operation, and issue possible follow-up calls - to the Registrar. + to the Registration Entity. Clients may be denied access to change the DS records for domains that are Registry Locked (HTTP Status code 401). Registry Lock is a mechanism provided by certain Registries or Registrars that prevents domain hijacking by ensuring no attributes of the domain are changeable, and no transfer or deletion transactions can be processed against the domain name without manual intervention. 4.1. Authentication The API does not impose any unique server authentication requirements. The server authentication provided by TLS fully addresses the needs of this protocol. The API MUST be provided over TLS-protected transport (e.g., HTTPS) or VPN. Client authentication is considered out of scope of this document. - The publication of CDS/CDNSKEY records in the child zone is an - indication that the child operator intends to perform DS-record- - updating activities (add/delete) in the parent zone. Since this - protocol is simply a signal to the Registrar that they should examine + The publication of CDS records in the child zone is an indication + that the child operator intends to perform DS-record-updating + activities (add/delete) in the parent zone. Since this protocol is + simply a signal to the Registration Entity that they should examine the child zone for such intentions, additional authentication of the client making the request is considered unnecessary. - Registrars MAY implement their own policy to protect access to the - API, such as with IP whitelisting, client TLS certificates, etc.. - Registrars SHOULD take steps to ensure that a lack of additional - authentication does not open up a denial of service mechanism against - the systems of the Registrar, the Registry, or the child operator. + Registration Entities MAY implement their own policy to protect + access to the API, such as with IP white listing, client TLS + certificates, etc.. Registration Entities SHOULD take steps to + ensure that a lack of additional authentication does not open up a + denial of service mechanism against the systems of the Registration + Entity, the Registry, or the child operator. 4.2. RESTful Resources In the following text, "{domain}" is the child zone to be operated on. 4.2.1. CDS resource Path: /domains/{domain}/cds @@ -343,36 +371,36 @@ o HTTP Status code 409 indicates the delegation already has a DS RRset. o HTTP Status code 429 indicates the client has been rate-limited. o HTTP Status code 500 indicates a failure due to unforeseeable reasons. This request is for setting up initial trust in the delegation. The - Registrar SHOULD return a status code 409 if it already has a DS - RRset for the child zone. + Registration Entity SHOULD return a status code 409 if it already has + a DS RRset for the child zone. Upon receipt of a 403 response the child operator SHOULD issue a POST for the "token" resource to fetch a challenge token to insert into the zone. 4.2.1.2. Removing DS Records 4.2.1.2.1. Request Syntax: DELETE /domains/{domain}/cds - Request that the Registrar check for a null CDS or CDNSKEY record in - the child zone, indicating a request that the entire DS RRset be - removed. This will make the delegation insecure. + Request that the Registration Entity check for a null CDS or CDNSKEY + record in the child zone, indicating a request that the entire DS + RRset be removed. This will make the delegation insecure. 4.2.1.2.2. Response o HTTP Status code 200 indicates a success. o HTTP Status code 400 indicates a failure due to validation. o HTTP Status code 401 indicates an unauthorized resource access. o HTTP Status code 404 indicates the domain does not exist. @@ -383,24 +411,25 @@ o HTTP Status code 500 indicates a failure due to unforeseeable reasons. 4.2.1.3. Modifying DS Records 4.2.1.3.1. Request Syntax: PUT /domains/{domain}/cds - Request that the Registrar modify the DS RRset based on the CDS/ - CDNSKEY available in the child zone. As a result of this request the - Registrar SHOULD add or delete DS records as indicated by the CDS/ - CDNSKEY RRset, but MUST NOT delete the entire DS RRset. + Request that the Registration Entity modify the DS RRset based on the + CDS/CDNSKEY available in the child zone. As a result of this request + the Registration Entity SHOULD add or delete DS or DNSKEY records as + indicated by the CDS/CDNSKEY RRset, but MUST NOT delete the entire DS + RRset. 4.2.1.3.2. Response o HTTP Status code 200 indicates a success. o HTTP Status code 400 indicates a failure due to validation. o HTTP Status code 401 indicates an unauthorized resource access. o HTTP Status code 404 indicates the domain does not exist. @@ -415,143 +444,160 @@ 4.2.2. Token resource Path: /domains/{domain}/token 4.2.2.1. Establish Initial Trust with Challenge 4.2.2.1.1. Request Syntax: GET /domains/{domain}/token - The DNSSEC policy of the Registrar may require proof that the DNS - Operator is in control of the domain. The token API call returns a - random token to be included as a TXT record for the _delegate.@ - domain name (where @ is the apex of the child zone) prior + The DNSSEC policy of the Registration Entity may require proof that + the DNS Operator is in control of the domain. The token API call + returns a random token to be included as a TXT record for the + _delegate.@ domain name (where @ is the apex of the child zone) prior establishing the DNSSEC initial trust. This is an additional trust control mechanism to establish the initial chain of trust. Once the child operator has received a token, it SHOULD be inserted in the zone and the operator SHOULD proceed with a POST of the cds resource. - The Registrar MAY expire the token after a reasonable period. The - Registrar SHOULD document an explanation of whether and when tokens - are expired in their DNSSEC policy. + The Registration Entity MAY expire the token after a reasonable + period. The Registration Entity SHOULD document an explanation of + whether and when tokens are expired in their DNSSEC policy. Note that the _delegate TXT record is publicly available and not a secret token. 4.2.2.1.2. Response o HTTP Status code 200 indicates a success. A token is included in the body of the response, as a valid TXT record o HTTP Status code 404 indicates the domain does not exist. o HTTP Status code 500 indicates a failure due to unforeseeable reasons. 4.3. Customized Error Messages - Registrars MAY provide a customized error message in the response - body in addition to the HTTP status code defined in the previous - section. This response MAY include an identifying number/string that - can be used to track the request. + Registration Entities MAY provide a customized error message in the + response body in addition to the HTTP status code defined in the + previous section. This response MAY include an identifying number/ + string that can be used to track the request. 5. Security considerations When zones are properly provisioned, and delegations follow standards and best practices (e.g. - [I-D.wallstrom-dnsop-dns-delegation-requirements]), the Registrar or - Registry can trust the DNS information it receives from multiple - child name servers, over time, and/or over TCP to establish the - initial chain of trust. + [I-D.wallstrom-dnsop-dns-delegation-requirements]), the Registration + Entity or Registry can trust the DNS information it receives from + multiple child name servers, over time, and/or over TCP to establish + the initial chain of trust. - In addition, the Registrar or Registry can require the DNS Operator - to prove they control the zone by requiring the child operator to - navigate additional hurdles, such as adding a challenge token to the - zone. + In addition, the Registration Entity or Registry can require the DNS + Operator to prove they control the zone by requiring the child + operator to navigate additional hurdles, such as adding a challenge + token to the zone. This protocol should increase the adoption of DNSSEC, enabling more zones to become validated thus overall the security gain outweighs the possible drawbacks. Registrants and DNS Operators always have the option to establish the chain of trust in band via the standard Registrant/Registrar/Registry model. 6. IANA Actions This document has no actions for IANA 7. Internationalization Considerations This protocol is designed for machine to machine communications. - Clients and servers should use punycode [RFC3492] when operating on + Clients and servers SHOULD use punycode [RFC3492] when operating on internationalized domain names. 8. References 8.1. Normative References [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, - . + . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, - . + . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating - DNSSEC Delegation Trust Maintenance", RFC 7344, DOI - 10.17487/RFC7344, September 2014, - . + DNSSEC Delegation Trust Maintenance", RFC 7344, + DOI 10.17487/RFC7344, September 2014, + . [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from - the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/ - RFC8078, March 2017, - . + the Parent via CDS/CDNSKEY", RFC 8078, + DOI 10.17487/RFC8078, March 2017, + . 8.2. Informative References + [I-D.ietf-dnsop-terminology-bis] + Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", draft-ietf-dnsop-terminology-bis-06 (work in + progress), July 2017. + [I-D.wallstrom-dnsop-dns-delegation-requirements] Wallstrom, P. and J. Schlyter, "DNS Delegation Requirements", draft-wallstrom-dnsop-dns-delegation- requirements-03 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, - . + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . - [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI - 10.17487/RFC3912, September 2004, - . + [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, + DOI 10.17487/RFC3912, September 2004, + . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, - . - - [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A - Framework for DNSSEC Policies and DNSSEC Practice - Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, - . + . [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the - Registration Data Access Protocol (RDAP)", RFC 7480, DOI - 10.17487/RFC7480, March 2015, - . + Registration Data Access Protocol (RDAP)", RFC 7480, + DOI 10.17487/RFC7480, March 2015, + . + + [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", RFC 7719, DOI 10.17487/RFC7719, December + 2015, . Appendix A. Document History -A.1. regext Version 03 +A.1. regext Version 04 + + o changed uses of Registrar to Registration Entity and updated + definitions to improve clarity + + o adding note about CDS/CDNSKEY interchangability in this document + + o added advice to scan all delegations (including insecure + delegations) for CDS in order to bootstrap or update DNSSEC + + o removed "Other Delegation Maintenance" section, since we decided a + while ago not to use this to update NS + +A.2. regext Version 03 o simplify abstract o move all justification text to Intro o added HTTP response codes for rate limiting (429), missing DS RRsets (412) o expanded on Internationalization Considerations @@ -559,55 +605,56 @@ o clarify parent/Registrar references in the draft o general spelling/grammar/style cleanup o removed references to NS and glue maintenance o clarify content of POST body for 'cds' resource o change verb for obtaining a 'token' to GET - o Updated refernce to RFC8078 -A.2. regext Version 02 + o Updated reference to RFC8078 + +A.3. regext Version 02 o Clarified based on comments and questions from early implementors (JL) o Text edits and clarifications. -A.3. regext Version 01 +A.4. regext Version 01 o Rewrote Abstract and Into (MP) o Introduced code 401 when changes are not allowed o Text edits and clarifications. -A.4. regext Version 00 +A.5. regext Version 00 o Working group document same as 03, just track changed to standard -A.5. Version 03 +A.6. Version 03 o Clarified based on comments and questions from early implementors -A.6. Version 02 +A.7. Version 02 o Reflected comments on mailing lists -A.7. Version 01 +A.8. Version 01 o This version adds a full REST definition this is based on suggestions from Jakob Schlyter. -A.8. Version 00 +A.9. Version 00 o First rough version Authors' Addresses Jacques Latour CIRA Ottawa, ON Email: jacques.latour@cira.ca