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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/