draft-ietf-regext-dnsoperator-to-rrr-protocol-01.txt   draft-ietf-regext-dnsoperator-to-rrr-protocol-02.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: January 8, 2017 Cloudflare, Inc. Expires: July 14, 2017 Cloudflare, Inc.
P. Wouters P. Wouters
Red Hat Red Hat
M. Pounsett M. Pounsett
Rightside Group, Ltd. Rightside Group, Ltd.
July 7, 2016 January 10, 2017
Third Party DNS operator to Registrars/Registries Protocol Third Party DNS operator to Registrars/Registries Protocol
draft-ietf-regext-dnsoperator-to-rrr-protocol-01.txt draft-ietf-regext-dnsoperator-to-rrr-protocol-02.txt
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 on the other hand uses DNSSEC it necessary to make When the domain hand uses DNSSEC it necessary to make regular
regular (sometimes annual) changes to the delegation, in order to (sometimes annual) changes to the delegation, updating DS record(s)
track KSK rollover, by updating the delegation's DS record(s). Under in order to track KSK rollover. Under the current model this is
the current model this is prone to delays and errors. Even when the prone to delays and errors, as the Registrant must participate in
Registrant has outsourced the operation of DNS to a third party the updates to DS records.
registrant still has to be in the loop to update the DS record.
There is a need for a simple protocol that allows a third party DNS
operator to update DS and NS records in a trusted manner for a
delegation without involving the registrant for each operation. This
same protocol can be used by Registrants.
The protocol described in this draft is REST based, and when used This document describes a simple protocol that allows a third party
through an authenticated channel can be used to establish the DNSSEC DNS operator to update DS and NS records for a delegation, in a
Initial Trust (to turn on DNSSEC or bootstrap DNSSEC). Once DNSSEC trusted manner, without involving the Registrant for each operation.
trust is established this channel can be used to trigger maintenance This same protocol can be used by Registrants.
of delegation records such as DS, NS, and glue records. The protocol
is kept as simple as possible.
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 http://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 January 8, 2017. This Internet-Draft will expire on July 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (http://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. What is the goal? . . . . . . . . . . . . . . . . . . . . . . 4 3. Process Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Why DNSSEC? . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Identifying the Registrar . . . . . . . . . . . . . . . . 4
3.2. How does a child signal its parent it wants DNSSEC Trust 3.2. Establishing a Chain of Trust . . . . . . . . . . . . . . 5
Anchor? . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Maintaining the Chain of Trust . . . . . . . . . . . . . 5
3.3. What checks are needed by parent? . . . . . . . . . . . . 5 3.4. Other Delegation Maintenance . . . . . . . . . . . . . . 5
4. Third Party DNS operator to Registrars/Registries RESTful API 6 3.5. Acceptance Processing . . . . . . . . . . . . . . . . . . 5
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 6 4. API Definition . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7
4.3. Base URL Locator . . . . . . . . . . . . . . . . . . . . 6 4.2. RESTful Resources . . . . . . . . . . . . . . . . . . . . 7
4.4. CDS resource . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. CDS resource . . . . . . . . . . . . . . . . . . . . 7
4.4.1. Initial Trust Establishment (Enable DNSSEC 4.2.2. Token resource . . . . . . . . . . . . . . . . . . . 9
validation) . . . . . . . . . . . . . . . . . . . . . 6 4.3. Customized Error Messages . . . . . . . . . . . . . . . . 10
4.4.2. Removing a DS (turn off DNSSEC) . . . . . . . . . . . 7 5. Security considerations . . . . . . . . . . . . . . . . . . . 10
4.4.3. DS Maintenance (Key roll over) . . . . . . . . . . . 8 6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Tokens resource . . . . . . . . . . . . . . . . . . . . . 8 7. Internationalization Considerations . . . . . . . . . . . . . 11
4.5.1. Setup Initial Trust Establishment with Challenge . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Customized Error Messages . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
4.7. How to react to 403 on POST cds . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 11
5. Security considerations . . . . . . . . . . . . . . . . . . . 9 Appendix A. Document History . . . . . . . . . . . . . . . . . . 12
6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 9 A.1. regext Version 02 . . . . . . . . . . . . . . . . . . . . 12
7. Internationalization Considerations . . . . . . . . . . . . . 10 A.2. regext Version 02 not pushed . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.3. regext Version 01 . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 A.4. regext Version 00 . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 10 A.5. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Document History . . . . . . . . . . . . . . . . . . 11 A.6. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 13
A.1. Regex versio 01 . . . . . . . . . . . . . . . . . . . . . 11 A.7. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 13
A.2. Regex version 00 . . . . . . . . . . . . . . . . . . . . 11 A.8. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 13
A.3. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
A.4. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 11
A.5. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 11
A.6. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Why is this needed? DNS registration systems today are designed After a domain has been registered, one of three parties will
around making registrations easy and fast. After the domain has been maintain the DNS zone loaded on the "primary" DNS servers: the
registered there are really three options on who maintains the DNS Registrant, the Registrar, or a third party DNS operator. DNS
zone that is loaded on the "primary" DNS servers for the domain this registration systems were originally designed around making
can be the Registrant, Registrar, or a third party DNS Operator. registrations easy and fast, however after registration the
complexity of making changes to the delegation differs for each of
Unfortunately the ease to make changes differs for each one of these these parties. The Registrar can make changes directly in the
options. The Registrant needs to use the interface that the Registry systems through some API (typically EPP [RFC5730]). The
registrar provides to update NS and DS records. The Registrar on the Registrant is typically limited to using a web interface supplied by
other hand can make changes directly into the registration system. the Registrar. A third party DNS Operator must to go through the
The third party DNS Operator on the hand needs to go through the
Registrant to update any delegation information. Registrant to update any delegation information.
Current system does not work well, there are many types of failures In this last case, the operator must contact and engage the
have been reported and they have been at all levels in the Registrant in updating NS and DS records for the delegation. New
registration model. 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 failures result either inability to use DNSSEC or in validation The current system does not work well, as there are many types of
failures that case the domain to become invalid and all users that failures that have been reported at all levels in the registration
are behind validating resolvers will not be able to to access the model. The failures result in either the inability to use DNSSEC or
domain. in validation failures that cause the domain to become unavailable to
users behind validating resolvers.
The goal of this document is to create an automated interface that The goal of this document is to create a protocol for establishing a
will reduce the friction in maintaining DNSSEC delegations. secure chain of trust that involves parties not in the traditional
Registrant/Registrar/Registry (RRR) model, and to reduce the friction
in maintaining DNSSEC secured delegations in these cases. It
describes a REST-based [RFC6690] protocol which can be used to
establish DNSSEC initial trust (to enable or bootstrap DNSSEC), and
to trigger maintenance of delegation records such as DS, NS, and glue
records.
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 the word 'Registrar' in this document may also be applied to Uses of "child" and "parent" refer to the relationship between DNS
resellers: an entity that sells delegations through a registrar with zone operators. In this document, unless otherwise noted, the child
whom the entity has a reseller agreement. 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.
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. What is the goal? 3. Process Overview
The primary goal is to have a protocol to establish a secure chain of 3.1. Identifying the Registrar
trust that involves parties that are not in the traditional RRR EPP
model, or when EPP is not used.
In the general case there should be a way to find the right As of publication of this document, there has never been a
Registrar/Registry entity to talk to, but it does not exist. Whois[] standardized or widely deployed method for easily and scalably
is the natural protocol to carry such information but that protocol identifying the Registar for a particular registration.
but is unreliable and hard to parse. Its proposed successor RDAP
[RFC7480] has yet be deployed on most TLD's.
The preferred communication mechanism is to use is to use a REST At this time, WHOIS [RFC3912] is the only widely deployed protocol to
[RFC6690] call to start processing of the requested delegation carry such information, but WHOIS responses are unstructured text,
information. 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.
3.1. Why DNSSEC? 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.
DNSSEC [RFC4035] provides data authentication for DNS answers, having With no current mechanism in place to scalably discover the Registar
DNSSEC enabled makes it possible to trust the answers. The biggest for a particular registration, the problem of automatic discovery of
obstacle in DNSSEC adoption is the initial configuration of the the base URL of the API is considered out of scope of this document.
DNSSEC domain trust anchor at the parent, the DS record.
3.2. How does a child signal its parent it wants DNSSEC Trust Anchor? The authors recommend standardization of an RDAP extension to obtain
this information from the Registry.
The child needs first to sign the domain, then the child can "upload" 3.2. Establishing a Chain of Trust
the DS record to its parent. The "normal" way to upload is to go
through registration interface, but that fails frequently. The DNS
Operator may not have access to the interface thus the registrant
needs to relay the information. For large operations this does not
scale, as evident in lack of Trust Anchors for signed deployments
that are operated by third parties.
The child can signal its desire to have DNSSEC validation enabled by After signing the zone, the child operator needs to upload the DS
publishing one of the special DNS records CDS and/or CDNSKEY[RFC7344] record(s) to the parent. The child can signal its desire to have
and its proposed extension [I-D.ietf-dnsop-maintain-ds]. DNSSEC validation enabled by publishing one of the special DNS
records CDS and/or CDNSKEY as defined in [RFC7344] and
[I-D.ietf-dnsop-maintain-ds].
Once the "parent" "sees" these records it SHOULD start acceptance [RFC Editor: The above I-D reference should be replaced with the
processing. This document covers how to make the CDS records visible correct RFC number upon publication.]
to the right parental agent.
This document and [I-D.ogud-dnsop-maintain-ds] argue that the In the case of an insecure delegation, the Registrar will normally
publication of CDS/CDNSKEY record is sufficient for the parent to not be scanning the child zone for CDS/CDNSKEY records. The child
start the acceptance processing. The main point is to provide operator can use this protocol to notify the Registrar to begin such
authentication thus if the child is in "good" state then the DS a scan.
upload should be simple to accept and publish. If there is any
problem the parent does not add the DS.
In the event this protocols and its associated authentication Once the Registrar sees these records it SHOULD start acceptance
mechanism does not address the Registrant's security requirements to processing.
create a secure Trust Anchor delegation then the Registrant always
has recourse by submitting its DS record via its Registrar interface
with EPP submission to the Registry.
3.3. What checks are needed by parent? 3.3. Maintaining the Chain of Trust
The parent upon receiving a signal that it check the child for desire One the secure chain of trust is established, the Registrar SHOULD
for DS record publication. The basic tests include, 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.
1. Is the zone is signed Server implementations of this protocol MAY include rate limiting to
2. The zone has a CDS signed by a KSK referenced in the current DS, protect their systems and the systems of child operators from abuse.
referring to a at least one key in the current DNSKEY RRset
3. All the name-servers for the zone agree on the CDS RRset contents
Parents can perform additional tests, defined delays, queries over Each parent operator and Registrar is responsible for developing,
TCP, ensure zone delegation best practice as per implementing, and communicating their DNSSEC maintenance policies.
[I-D.wallstrom-dnsop-dns-delegation-requirements] and even ask the
DNS Operator to prove they can add data to the zone, or provide a
code that is tied to the affected zone. The protocol is partially-
synchronous, i.e. the server can elect to hold connection open until
the operation has concluded or it can return that it received the
request. It is up to the child to monitor the parent for completion
of the operation and issue possible follow-up calls.
4. Third Party DNS operator to Registrars/Registries RESTful API 3.4. Other Delegation Maintenance
The specification of this API is minimalist, but a realistic one. [ Not yet defined ]
Registry Lock mechanisms that prevents domain hijacking block domains 3.5. Acceptance Processing
prevent certain attributes in the registry to be changed. This API
may be denied access to change the DS records for domains that are The Registrar, upon receiving a signal or detecting through polling
Registry Locked (HTTP Status code 401). 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 if updating the DS record, checking that 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.
[NOTE: Do we need a new section in the DPS for the CDS management
policy [RFC6841]?]
Registrars MAY require compliance with additional tests, particularly
in the case of establishing a new chain of trust, such as:
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 requiring the child name servers to respond with identical CDS/
CDNSKEY RRsets over TCP
o ensuring zone delegation best practices (for examples, see
[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)
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.
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 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. In general, the API SHOULD 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.
4.2. Authorization 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 child zone for such intentions, additional authentication of the
client making the request is considered unnecessary.
Authorization is outside the scope of this document. The CDS records Registrars MAY implement their own policy to protect access to the
present in the zone file are indications of intention to sign/unsign/ API, such as with IP whitelisting, client TLS certificates, etc..
update the DS records of the domain in the parent zone. This means Registrars SHOULD take steps to ensure that a lack of additional
the proceeding of the action is not determined by who issued the authentication does not open up a denial of service mechanism against
request. Therefore, authorization is out of scope. Registries and the systems of the Registrar, the Registry, or the child operator.
registrars who plan to provide this service can, however, implement
their own policy such as IP white listing, API key, etc.
4.3. Base URL Locator 4.2. RESTful Resources
The base URL for registries or registrars who want to provide this In the following text, "{domain}" is the child zone to be operated
service to DNS Operators can be made auto-discoverable as an RDAP on.
extension.
4.4. CDS resource 4.2.1. CDS resource
Path: /domains/{domain}/cds {domain}: is the domain name to be Path: /domains/{domain}/cds
operated on
4.4.1. Initial Trust Establishment (Enable DNSSEC validation) 4.2.1.1. Establishing Initial Trust (Enabling DNSSEC)
4.4.1.1. Request 4.2.1.1.1. Request
Syntax: POST /domains/{domain}/cds Syntax: POST /domains/{domain}/cds
A DS record based on the CDS record in the child zone file will be Request that an initial set of DS records based on the CDS record in
inserted into the registry and the parent zone file upon the the child zone be inserted into the Registry and the parent zone upon
successful completion of such request. If there are multiple CDS the successful completion of the request. If there are multiple CDS
records in the CDS RRset, multiple DS records will be added. records in the CDS RRset, multiple DS records will be added.
Either the CDS/CDNSKEY or the DNSKEY can be used to create the DS 4.2.1.1.2. Response
record. Note: entity expecting CDNSKEY is still expected accept the
/cds command.
4.4.1.2. Response
o HTTP Status code 201 indicates a success. o HTTP Status code 201 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 403 indicates a failure due to an invalid o HTTP Status code 403 indicates a failure due to an invalid
challenge token. challenge token.
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 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 o HTTP Status code 500 indicates a failure due to unforeseeable
reasons. reasons.
4.4.2. Removing a DS (turn off DNSSEC) 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.
4.4.2.1. Request 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.
Syntax: DELETE /domains/{domain}/cds 4.2.1.2. Removing DS Records
A null CDS or CDNSKEY record mean the entire DS RRset must be 4.2.1.2.1. Request
removed.
4.4.2.2. Response 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.
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.
o HTTP Status code 412 indicates the parent does not have 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 o HTTP Status code 500 indicates a failure due to unforeseeable
reasons. reasons.
4.4.3. DS Maintenance (Key roll over) 4.2.1.3. Modifying DS Records
4.4.3.1. Request 4.2.1.3.1. Request
Syntax: PUT /domains/{domain}/cds Syntax: PUT /domains/{domain}/cds
Maintenance activities are performed based on the CDS available in Request that the Registrar modify the DS RRset based on the CDS/
the child zone. DS records may be added, removed. But the entire DS CDNSKEY available in the child zone. As a result of this request the
RRset must not be deleted. Registrar SHOULD add or delete DS records as indicated by the CDS/
CDNSKEY RRset, but MUST NOT delete the entire DS RRset.
4.4.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.
o HTTP Status code 412 indicates the parent does not have 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 o HTTP Status code 500 indicates a failure due to unforeseeable
reasons. reasons.
4.5. Tokens resource 4.2.2. Token resource
Path: /domains/{domain}/tokens {domain}: is the domain name to be Path: /domains/{domain}/token
operated on
4.5.1. Setup Initial Trust Establishment with Challenge 4.2.2.1. Establish Initial Trust with Challenge
4.5.1.1. Request 4.2.2.1.1. Request
Syntax: POST /domains/{domain}/tokens Syntax: POST /domains/{domain}/token
A random token to be included as a _delegate TXT record prior The DNSSEC policy of the Registrar may require proof that the DNS
establishing the DNSSEC initial trust. 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.
4.5.1.2. Response 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.
o HTTP Status code 200 indicates a success. Token included in the Note that the _delegate TXT record is publicly available and not a
body of the response, as a valid TXT record 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 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.6. Customized Error Messages 4.3. Customized Error Messages
Service providers can provide a customized error message in the
response body in addition to the HTTP status code defined in the
previous section.
This can include an Identifying number/string that can be used to
track the requests.
#Using the definitions This section at the moment contains comments
from early implementers
4.7. How to react to 403 on POST cds
The basic reaction to a 403 on POST /domains/{domain}/cds is to issue Registrars MAY provide a customized error message in the response
POST /domains/{domain}/tokens command to fetch the challenge to body in addition to the HTTP status code defined in the previous
insert into the zone. section. This response MAY include an identifying number/string that
can be used to track the request.
5. Security considerations 5. Security considerations
Supplying the DS record as proof of control is not realistic since When zones are properly provisioned, and delegations follow standards
the domain is already publicly signed and the CDS/DS is readily and best practices (e.g.
available. [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.
Open question:?? JL?: It is not recommended the protocol be used with In addition, the Registrar or Registry can require the DNS Operator
high profile domains such as TLDs and governments that are DNS to prove they control the zone by requiring the child operator to
operators. This protocol is meant to allow third party DNS operator navigate additional hurdles, such as adding a challenge token to the
to submit the initial DS in a trusted manner without involving the zone.
registrant.
This protocol should increase the adoption of DNSSEC and get 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.
TBD This will hopefully get more zones to become validated thus Registrants and DNS Operators always have the option to establish the
overall the security gain out weights the possible drawbacks. chain of trust in band via the standard Registrant/Registrar/Registry
model.
risk of takeover ? risk of validation errors < declines transfer
issues
6. IANA Actions 6. IANA Actions
URI ??? TBD 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
internationalized domain names.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-dnsop-maintain-ds] [I-D.ietf-dnsop-maintain-ds]
Gudmundsson, O. and P. Wouters, "Managing DS records from Gudmundsson, O. and P. Wouters, "Managing DS records from
parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-03 parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-04
(work in progress), June 2016. (work in progress), October 2016.
[I-D.wallstrom-dnsop-dns-delegation-requirements] [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
Wallstrom, P. and J. Schlyter, "DNS Delegation for Internationalized Domain Names in Applications
Requirements", draft-wallstrom-dnsop-dns-delegation- (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
requirements-00 (work in progress), February 2016. <http://www.rfc-editor.org/info/rfc3492>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Rose, "Protocol Modifications for the DNS Security Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc6690>.
<http://www.rfc-editor.org/info/rfc4035>.
[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, DOI
10.17487/RFC7344, September 2014, 10.17487/RFC7344, September 2014,
<http://www.rfc-editor.org/info/rfc7344>. <http://www.rfc-editor.org/info/rfc7344>.
8.2. Informative References 8.2. Informative References
[I-D.ogud-dnsop-maintain-ds] [I-D.wallstrom-dnsop-dns-delegation-requirements]
Gu[eth]mundsson, O. and P. Wouters, "Managing DS records Wallstrom, P. and J. Schlyter, "DNS Delegation
from parent via CDS/CDNSKEY", draft-ogud-dnsop-maintain- Requirements", draft-wallstrom-dnsop-dns-delegation-
ds-00 (work in progress), October 2015. 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, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 10.17487/RFC3912, September 2004,
<http://www.rfc-editor.org/info/rfc6690>. <http://www.rfc-editor.org/info/rfc3912>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<http://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, DOI
10.17487/RFC7480, March 2015, 10.17487/RFC7480, March 2015,
<http://www.rfc-editor.org/info/rfc7480>. <http://www.rfc-editor.org/info/rfc7480>.
Appendix A. Document History Appendix A. Document History
A.1. Regex versio 01 A.1. regext Version 02
Rewrote Abstract and Into (MP) Introduced code 401 when changes are o simplify abstract
not allowed Text edits and clarifications.
A.2. Regex version 00 o move all justification text to Intro
Working group document same as 03, just track changed to standard o added HTTP response codes for rate limiting (429), missing DS
RRsets (412)
A.3. Version 03 o expanded on Internationalization Considerations
Clarified based on comments and questions from early implementors o corrected informative/normative document references
A.4. Version 02 o clarify parent/Registrar references in the draft
Reflected comments on mailing lists o general spelling/grammar/style cleanup
A.5. Version 01 A.2. regext Version 02 not pushed
This version adds a full REST definition this is based on suggestions o Clarified based on comments and questions from early implementors
from Jakob Schlyter. (JL)
A.6. Version 00 o Text edits and clarifications.
First rough version A.3. 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
o Working group document same as 03, just track changed to standard
A.5. Version 03
o Clarified based on comments and questions from early implementors
A.6. Version 02
o Reflected comments on mailing lists
A.7. Version 01
o This version adds a full REST definition this is based on
suggestions from Jakob Schlyter.
A.8. Version 00
o First rough version
Authors' Addresses Authors' Addresses
Jacques Latour Jacques Latour
CIRA CIRA
Email: jacques.latour@cira.ca Email: jacques.latour@cira.ca
Olafur Gudmundsson Olafur Gudmundsson
Cloudflare, Inc. Cloudflare, Inc.
 End of changes. 90 change blocks. 
255 lines changed or deleted 357 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/