<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" docName="draft-ietf-regext-dnsoperator-to-rrr-protocol-05">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="3-DNS-RRR">Third Party DNS operator to Registrars/Registries Protocol</title>

<author initials="J." surname="Latour" fullname="Jacques Latour">
<organization>CIRA</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<code></code>
<country></country>
<region>ON</region>
</postal>
<phone></phone>
<email>jacques.latour@cira.ca</email>
<uri></uri>
</address>
</author>
<author initials="O." surname="Gudmundsson" fullname="Olafur Gudmundsson">
<organization>Cloudflare, Inc.</organization>
<address>
<postal>
<street></street>
<city>San Francisco</city>
<code></code>
<country></country>
<region>CA</region>
</postal>
<phone></phone>
<email>olafur+ietf@cloudflare.com</email>
<uri></uri>
</address>
</author>
<author initials="P." surname="Wouters" fullname="Paul Wouters">
<organization>Red Hat</organization>
<address>
<postal>
<street></street>
<city>Toronto</city>
<code></code>
<country></country>
<region>ON</region>
</postal>
<phone></phone>
<email>paul@nohats.ca</email>
<uri></uri>
</address>
</author>
<author initials="M." surname="Pounsett" fullname="Matthew Pounsett">
<organization>Nimbus Operations Inc.</organization>
<address>
<postal>
<street></street>
<city>Toronto</city>
<code></code>
<country></country>
<region>ON</region>
</postal>
<phone></phone>
<email>matt@conundrum.com</email>
<uri></uri>
</address>
</author>
<date year="2018" month="May" day="4"/>

<area>Applications</area>
<workgroup>regext</workgroup>
<keyword>dnssec</keyword>
<keyword>delegation maintenance</keyword>
<keyword>trust anchors</keyword>


<abstract>
<t>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.
</t>
<t>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.
</t>
<t>This document describes a simple protocol that allows a third party 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.
</t>
</abstract>


</front>

<middle>

<section anchor="introduction" title="Introduction">
<t>After a domain has been registered, one of three parties will maintain the DNS zone loaded on the &quot;primary&quot; 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 <xref target="RFC5730"/>).  The Registrant is typically limited to using a web interface supplied by the Registrar or Reseller.  Typically, a third party DNS Operator must to go through the Registrant to update any delegation information.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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 in
maintaining DNSSEC secured delegations in these cases.  It describes a
REST-based <xref target="RFC6690"/> protocol which can be used to establish DNSSEC initial
trust (to enable or bootstrap DNSSEC), and to trigger maintenance of DS
records.
</t>
</section>

<section anchor="notional-conventions" title="Notional Conventions">

<section anchor="definitions" title="Definitions">
<t>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.
</t>
<t>Uses of &quot;child&quot; and &quot;parent&quot; refer to the relationship between DNS zone
operators (see <xref target="RFC7719"/> and <xref target="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.
</t>
<t>Use of the term &quot;Registration Entity&quot; 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.
</t>
<t>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 &quot;CDS&quot; or &quot;CDNSKEY&quot; can be assumed to also refer to the other.
</t>
</section>

<section anchor="rfc2119-keywords" title="RFC2119 Keywords">
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;,
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be
interpreted as described in <xref target="RFC2119"/>.
</t>
</section>
</section>

<section anchor="process-overview" title="Process Overview">

<section anchor="identifying-the-registration-entity" title="Identifying the Registration Entity">
<t>As of publication of this document, there has never been a standardized or
widely deployed method for easily and scalably identifying the Registration
Entity for a particular registration.
</t>
<t>At this time, WHOIS <xref target="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.
</t>
<t>RDAP, the successor to WHOIS, described in <xref target="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.
</t>
<t>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.
</t>
</section>

<section anchor="establishing-a-chain-of-trust" title="Establishing a Chain of Trust">
<t>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
<xref target="RFC7344"/> and <xref target="RFC8078"/>.
</t>
<t>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 <xref target="bootstrap"/> below when using CDS to bootstrap DNSSEC on a previously unsecured delegation.
</t>
<t>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.
</t>
<t>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.
</t>
</section>

<section anchor="maintaining-the-chain-of-trust" title="Maintaining the Chain of Trust">
<t>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.
</t>
<t>Server implementations of this protocol MAY include rate limiting to protect
their systems and the systems of child operators from abuse.
</t>
<t>Each parent operator and Registration Entity is responsible for developing,
implementing, and communicating their DNSSEC maintenance policies.
</t>
</section>

<section anchor="acceptance-processing" title="Acceptance Processing">
<t>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:
</t>
<t>
<list style="symbols">
<t>checks that the child zone is is properly signed as per the Registration Entity and parent DNSSEC policies</t>
<t>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</t>
<t>ensuring all name servers in the apex NS RRset of the child zone agree on the apex NS RRset and CDS RRset contents</t>
</list>
</t>
<t>The Registration Entity SHOULD NOT make any changes to the DS RRset if the
child name servers do not agree on the CDS content.
</t>
</section>

<section anchor="bootstrap" title="Bootstrapping DNSSEC">
<t>Registration Entities SHOULD require compliance with additional tests in the case of establishing a new chain of trust.
</t>
<t>
<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>The Registration Entity MAY require the child zone to implement zone delegation best practices as described in <xref target="I-D.wallstrom-dnsop-dns-delegation-requirements"/>.</t>
<t>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 <xref target="token"/> below.</t>
</list>
</t>
</section>
</section>

<section anchor="api-definition" title="API Definition">
<t>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 Registration Entity.
</t>
<t>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.
</t>

<section anchor="authentication" title="Authentication">
<t>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.
</t>
<t>Client authentication is considered out of scope of this document.  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.
</t>
<t>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.
</t>
</section>

<section anchor="restful-resources" title="RESTful Resources">
<t>In the following text, &quot;{domain}&quot; is the child zone to be operated on.
</t>

<section anchor="cds-resource" title="CDS resource">
<t>Path: /domains/{domain}/cds
</t>

<section anchor="establishing-initial-trust-enabling-dnssec" title="Establishing Initial Trust (Enabling DNSSEC)">

<section anchor="request" title="Request">
<t>Syntax: POST /domains/{domain}/cds
</t>
<t>Request that an initial set of DS records based on the CDS record in the child
zone be inserted into the Registry and the parent zone upon the successful
completion of the request. If there are multiple CDS records in the CDS RRset,
multiple DS records will be added.
</t>
<t>The body of the POST SHOULD be empty, however server implementations SHOULD
NOT reject nonempty requests.
</t>
</section>

<section anchor="response" title="Response">
<t>
<list style="symbols">
<t>HTTP Status code 201 indicates a success.</t>
<t>HTTP Status code 400 indicates a failure due to validation.</t>
<t>HTTP Status code 401 indicates an unauthorized resource access.</t>
<t>HTTP Status code 403 indicates a failure due to an invalid challenge token.</t>
<t>HTTP Status code 404 indicates the domain does not exist.</t>
<t>HTTP Status code 409 indicates the delegation already has a DS RRset.</t>
<t>HTTP Status code 429 indicates the client has been rate-limited.</t>
<t>HTTP Status code 500 indicates a failure due to unforeseeable reasons.</t>
</list>
</t>
<t>This request is for setting up initial trust in the delegation.  The
Registration Entity SHOULD return a status code 409 if it already has a DS
RRset for the child zone.
</t>
<t>Upon receipt of a 403 response the child operator SHOULD issue a POST for the
&quot;token&quot; resource to fetch a challenge token to insert into the zone.
</t>
</section>
</section>

<section anchor="removing-ds-records" title="Removing DS Records">

<section anchor="request-1" title="Request">
<t>Syntax: DELETE /domains/{domain}/cds
</t>
<t>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.
</t>
</section>

<section anchor="response-1" title="Response">
<t>
<list style="symbols">
<t>HTTP Status code 200 indicates a success.</t>
<t>HTTP Status code 400 indicates a failure due to validation.</t>
<t>HTTP Status code 401 indicates an unauthorized resource access.</t>
<t>HTTP Status code 404 indicates the domain does not exist.</t>
<t>HTTP Status code 412 indicates the parent does not have a DS RRset</t>
<t>HTTP Status code 429 indicates the client has been rate-limited.</t>
<t>HTTP Status code 500 indicates a failure due to unforeseeable reasons.</t>
</list>
</t>
</section>
</section>

<section anchor="modifying-ds-records" title="Modifying DS Records">

<section anchor="request-2" title="Request">
<t>Syntax: PUT /domains/{domain}/cds
</t>
<t>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.
</t>
</section>

<section anchor="response-2" title="Response">
<t>
<list style="symbols">
<t>HTTP Status code 200 indicates a success.</t>
<t>HTTP Status code 400 indicates a failure due to validation.</t>
<t>HTTP Status code 401 indicates an unauthorized resource access.</t>
<t>HTTP Status code 404 indicates the domain does not exist.</t>
<t>HTTP Status code 412 indicates the parent does not have a DS RRset</t>
<t>HTTP Status code 429 indicates the client has been rate-limited.</t>
<t>HTTP Status code 500 indicates a failure due to unforeseeable reasons.</t>
</list>
</t>
</section>
</section>
</section>

<section anchor="token" title="Token resource">
<t>Path: /domains/{domain}/token
</t>

<section anchor="establish-initial-trust-with-challenge" title="Establish Initial Trust with Challenge">

<section anchor="request-3" title="Request">
<t>Syntax: GET /domains/{domain}/token
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>Note that the _delegate TXT record is publicly available and not a secret
token.
</t>
</section>

<section anchor="response-3" title="Response">
<t>
<list style="symbols">
<t>HTTP Status code 200 indicates a success.  A token is included in the
 body of the response, as a valid TXT record</t>
<t>HTTP Status code 404 indicates the domain does not exist.</t>
<t>HTTP Status code 500 indicates a failure due to unforeseeable reasons.</t>
</list>
</t>
</section>
</section>
</section>
</section>

<section anchor="customized-error-messages" title="Customized Error Messages">
<t>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.
</t>
</section>
</section>

<section anchor="security-considerations" title="Security considerations">
<t>When zones are properly provisioned, and delegations follow standards and best
practices (e.g. <xref target="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.
</t>
<t>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.
</t>
<t>This protocol should increase the adoption of DNSSEC, enabling more zones to
become validated thus overall the security gain outweighs the possible
drawbacks.
</t>
<t>Registrants and DNS Operators always have the option to establish the chain of
trust in band via the standard Registrant/Registrar/Registry model.
</t>
</section>

<section anchor="iana-actions" title="IANA Actions">
<t>This document has no actions for IANA
</t>
</section>

<section anchor="internationalization-considerations" title="Internationalization Considerations">
<t>This protocol is designed for machine to machine communications.  Clients and
servers SHOULD use punycode <xref target="RFC3492"/> when operating on internationalized
domain names.
</t>
</section>

</middle>
<back>
<references title="Normative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3492.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6690.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7344.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8078.xml"?>
</references>
<references title="Informative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-terminology-bis.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.wallstrom-dnsop-dns-delegation-requirements.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3912.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7480.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7719.xml"?>
</references>

<section anchor="document-history" title="Document History">

<section anchor="regext-version-05" title="regext Version 05">
<t>
<list style="symbols">
<t>new version to keep the draft alive</t>
<t>updating author organization</t>
</list>
</t>
</section>

<section anchor="regext-version-04" title="regext Version 04">
<t>
<list style="symbols">
<t>changed uses of Registrar to Registration Entity and updated definitions
to improve clarity</t>
<t>adding note about CDS/CDNSKEY interchangability in this document</t>
<t>added advice to scan all delegations (including insecure delegations) for CDS in order to bootstrap or update DNSSEC</t>
<t>removed &quot;Other Delegation Maintenance&quot; section, since we decided a while ago not to use this to update NS</t>
</list>
</t>
</section>

<section anchor="regext-version-03" title="regext Version 03">
<t>
<list style="symbols">
<t>simplify abstract</t>
<t>move all justification text to Intro</t>
<t>added HTTP response codes for rate limiting (429), missing DS RRsets
(412)</t>
<t>expanded on Internationalization Considerations</t>
<t>corrected informative/normative document references</t>
<t>clarify parent/Registrar references in the draft</t>
<t>general spelling/grammar/style cleanup</t>
<t>removed references to NS and glue maintenance</t>
<t>clarify content of POST body for 'cds' resource</t>
<t>change verb for obtaining a 'token' to GET</t>
<t>Updated reference to RFC8078</t>
</list>
</t>
</section>

<section anchor="regext-version-02" title="regext Version 02">
<t>
<list style="symbols">
<t>Clarified based on comments and questions from early implementors (JL)</t>
<t>Text edits and clarifications.</t>
</list>
</t>
</section>

<section anchor="regext-version-01" title="regext Version 01">
<t>
<list style="symbols">
<t>Rewrote Abstract and Into (MP)</t>
<t>Introduced code 401 when changes are not allowed</t>
<t>Text edits and clarifications.</t>
</list>
</t>
</section>

<section anchor="regext-version-00" title="regext Version 00">
<t>
<list style="symbols">
<t>Working group document same as 03, just track changed to standard</t>
</list>
</t>
</section>

<section anchor="version-03" title="Version 03">
<t>
<list style="symbols">
<t>Clarified based on comments and questions from early implementors</t>
</list>
</t>
</section>

<section anchor="version-02" title="Version 02">
<t>
<list style="symbols">
<t>Reflected comments on mailing lists</t>
</list>
</t>
</section>

<section anchor="version-01" title="Version 01">
<t>
<list style="symbols">
<t>This version adds a full REST definition this is based on suggestions from
Jakob Schlyter.</t>
</list>
</t>
</section>

<section anchor="version-00" title="Version 00">
<t>
<list style="symbols">
<t>First rough version</t>
</list>
</t>
</section>
</section>

</back>
</rfc>
