< draft-ietf-regext-dnsoperator-to-rrr-protocol-00.txt   draft-ietf-regext-dnsoperator-to-rrr-protocol-01.txt >
Network Working Group J. Latour regext J. Latour
Internet-Draft CIRA Internet-Draft CIRA
Intended status: Standards Track O. Gudmundsson Intended status: Standards Track O. Gudmundsson
Expires: October 28, 2016 Cloudflare, Inc. Expires: January 8, 2017 Cloudflare, Inc.
P. Wouters P. Wouters
Red Hat Red Hat
M. Pounsett M. Pounsett
Rightside Group, Ltd. Rightside Group, Ltd.
April 26, 2016 July 7, 2016
Third Party DNS operator to Registrars/Registries Protocol Third Party DNS operator to Registrars/Registries Protocol
draft-ietf-regext-dnsoperator-to-rrr-protocol-00.txt draft-ietf-regext-dnsoperator-to-rrr-protocol-01.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 for the When the domain on the other hand uses DNSSEC it necessary to make
Registrant in this situation to make regular (sometimes annual) regular (sometimes annual) changes to the delegation, in order to
changes to the delegation in order to track KSK rollover, by updating track KSK rollover, by updating the delegation's DS record(s). Under
the delegation's DS record(s). Under the current model this is prone the current model this is prone to delays and errors. Even when the
to Registrant error and significant delays. Even when the Registrant Registrant has outsourced the operation of DNS to a third party the
has outsourced the operation of DNS to a third party the registrant registrant still has to be in the loop to update the DS record.
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 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 operator to update DS and NS records in a trusted manner for a
delegation without involving the registrant for each operation. 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 The protocol described in this draft is REST based, and when used
through an authenticated channel can be used to establish the DNSSEC through an authenticated channel can be used to establish the DNSSEC
Initial Trust (to turn on DNSSEC or bootstrap DNSSEC). Once DNSSEC Initial Trust (to turn on DNSSEC or bootstrap DNSSEC). Once DNSSEC
trust is established this channel can be used to trigger maintenance trust is established this channel can be used to trigger maintenance
of delegation records such as DS, NS, and glue records. The protocol of delegation records such as DS, NS, and glue records. The protocol
is kept as simple as possible. is kept as simple as possible.
Status of This Memo Status of This Memo
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 October 28, 2016. This Internet-Draft will expire on January 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
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. What is the goal? . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Why DNSSEC? . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Why DNSSEC? . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. How does a child signal its parent it wants DNSSEC Trust 3.2. How does a child signal its parent it wants DNSSEC Trust
Anchor? The child . . . . . . . . . . . . . . . . . . . 4 Anchor? . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. What checks are needed by parent? . . . . . . . . . . . . 5 3.3. What checks are needed by parent? . . . . . . . . . . . . 5
4. OP-3-DNS-RR RESTful API . . . . . . . . . . . . . . . . . . . 5 4. Third Party DNS operator to Registrars/Registries RESTful API 6
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 6 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 6
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Base URL Locator . . . . . . . . . . . . . . . . . . . . 6 4.3. Base URL Locator . . . . . . . . . . . . . . . . . . . . 6
4.4. CDS resource . . . . . . . . . . . . . . . . . . . . . . 6 4.4. CDS resource . . . . . . . . . . . . . . . . . . . . . . 6
4.4.1. Initial Trust Establishment (Enable DNSSEC 4.4.1. Initial Trust Establishment (Enable DNSSEC
validation) . . . . . . . . . . . . . . . . . . . . . 6 validation) . . . . . . . . . . . . . . . . . . . . . 6
4.4.2. Removing a DS (turn off DNSSEC) . . . . . . . . . . . 7 4.4.2. Removing a DS (turn off DNSSEC) . . . . . . . . . . . 7
4.4.3. DS Maintenance (Key roll over) . . . . . . . . . . . 7 4.4.3. DS Maintenance (Key roll over) . . . . . . . . . . . 8
4.5. Tokens resource . . . . . . . . . . . . . . . . . . . . . 7 4.5. Tokens resource . . . . . . . . . . . . . . . . . . . . . 8
4.5.1. Setup Initial Trust Establishment with Challenge . . 8 4.5.1. Setup Initial Trust Establishment with Challenge . . 8
4.6. Customized Error Messages . . . . . . . . . . . . . . . . 8 4.6. Customized Error Messages . . . . . . . . . . . . . . . . 9
4.7. How to react to 403 on POST cds . . . . . . . . . . . . . 8 4.7. How to react to 403 on POST cds . . . . . . . . . . . . . 9
5. Security considerations . . . . . . . . . . . . . . . . . . . 8 5. Security considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Internationalization Considerations . . . . . . . . . . . . . 9 7. Internationalization Considerations . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Document History . . . . . . . . . . . . . . . . . . 10 Appendix A. Document History . . . . . . . . . . . . . . . . . . 11
A.1. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 10 A.1. Regex versio 01 . . . . . . . . . . . . . . . . . . . . . 11
A.2. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. Regex version 00 . . . . . . . . . . . . . . . . . . . . 11
A.3. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 10 A.3. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 11
A.4. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 10 A.4. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 Why is this needed? DNS registration systems today are designed
around making registrations easy and fast. After the domain has been around making registrations easy and fast. After the domain has been
registered the there are really three options on who maintains the registered there are really three options on who maintains the DNS
DNS zone that is loaded on the "primary" DNS servers for the domain zone that is loaded on the "primary" DNS servers for the domain this
this can be the Registrant, Registrar, or a third party DNS Operator. can be the Registrant, Registrar, or a third party DNS Operator.
Unfortunately the ease to make changes differs for each one of these Unfortunately the ease to make changes differs for each one of these
options. The Registrant needs to use the interface that the options. The Registrant needs to use the interface that the
registrar provides to update NS and DS records. The Registrar on the registrar provides to update NS and DS records. The Registrar on the
other hand can make changes directly into the registration system. other hand can make changes directly into the registration system.
The third party DNS Operator on the hand needs 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 examples of Current system does not work well, there are many types of failures
failures including the inability to upload DS records due to non- have been reported and they have been at all levels in the
support by Registrar interface, the registrant forgets/does-not registration model.
perform action but tools proceed with key roll-over without checking
that the new DS is in place. Another common failure is the DS record
is not removed when the DNS Operator changes from one that supports
DNSSEC signing to one that does not.
The failures result either inability to use DNSSEC or in validation The failures result either inability to use DNSSEC or in validation
failures that case the domain to become invalid and all users that failures that case the domain to become invalid and all users that
are behind validating resolvers will not be able to to access the are behind validating resolvers will not be able to to access the
domain. domain.
The goal of this document is to create an automated interface that
will reduce the friction in maintaining DNSSEC delegations.
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 the word 'Registrar' in this document may also be applied to
resellers: an entity that sells delegations through a registrar with resellers: an entity that sells delegations through a registrar with
whom the entity has a reseller agreement. whom the entity has a reseller agreement.
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. What is the goal?
The primary goal is to use the DNS protocol to provide information The primary goal is to have a protocol to establish a secure chain of
from child zone to the parent zone, to maintain the delegation trust that involves parties that are not in the traditional RRR EPP
information. The precondition for this to be practical is that the model, or when EPP is not used.
domain is DNSSEC signed.
In the general case there should be a way to find the right In the general case there should be a way to find the right
Registrar/Registry entity to talk to but that does not exist. Registrar/Registry entity to talk to, but it does not exist. Whois[]
Whois[] is the natural protocol to carry such information but that is the natural protocol to carry such information but that protocol
protocol is unreliable and hard to parse. Its proposed successor but is unreliable and hard to parse. Its proposed successor RDAP
RDAP [RFC7480] has yet be deployed on most TLD's. [RFC7480] has yet be deployed on most TLD's.
The preferred communication mechanism is to use is to use a REST The preferred communication mechanism is to use is to use a REST
[RFC6690] call to start processing of the requested delegation [RFC6690] call to start processing of the requested delegation
information. information.
3.1. Why DNSSEC? 3.1. Why DNSSEC?
DNSSEC [RFC4035] provides data authentication for DNS answers, having DNSSEC [RFC4035] provides data authentication for DNS answers, having
DNSSEC enabled makes it possible to trust the answers. The biggest DNSSEC enabled makes it possible to trust the answers. The biggest
stumbling block is deploying DNSSEC is the initial configuration of obstacle in DNSSEC adoption is the initial configuration of the
the DNSSEC domain trust anchor in the parent, DS record. DNSSEC domain trust anchor at the parent, the DS record.
3.2. How does a child signal its parent it wants DNSSEC Trust Anchor? 3.2. How does a child signal its parent it wants DNSSEC Trust Anchor?
The child
needs first to sign the domain, then the child can "upload" the DS The child needs first to sign the domain, then the child can "upload"
record to its parent. The "normal" way to upload is to go through the DS record to its parent. The "normal" way to upload is to go
registration interface, but that fails frequently. The DNS Operator through registration interface, but that fails frequently. The DNS
may not have access to the interface thus the registrant needs to Operator may not have access to the interface thus the registrant
relay the information. For large operations this does not scale, as needs to relay the information. For large operations this does not
evident in lack of Trust Anchors for signed deployments that are scale, as evident in lack of Trust Anchors for signed deployments
operated by third parties. that are operated by third parties.
The child can signal its desire to have DNSSEC validation enabled by The child can signal its desire to have DNSSEC validation enabled by
publishing one of the special DNS records CDS and/or CDNSKEY[RFC7344] publishing one of the special DNS records CDS and/or CDNSKEY[RFC7344]
and its proposed extension [I-D.ietf-dnsop-maintain-ds]. and its proposed extension [I-D.ietf-dnsop-maintain-ds].
Once the "parent" "sees" these records it SHOULD start acceptance Once the "parent" "sees" these records it SHOULD start acceptance
processing. This document will cover below how to make the CDS processing. This document covers how to make the CDS records visible
records visible to the right parental agent. to the right parental agent.
We and [I-D.ogud-dnsop-maintain-ds] argue that the publication of This document and [I-D.ogud-dnsop-maintain-ds] argue that the
CDS/CDNSKEY record is sufficient for the parent to start the publication of CDS/CDNSKEY record is sufficient for the parent to
acceptance processing. The main point is to provide authentication start the acceptance processing. The main point is to provide
thus if the child is in "good" state then the DS upload should be authentication thus if the child is in "good" state then the DS
simple to accept and publish. If there is a problem the parent has upload should be simple to accept and publish. If there is any
ability to not add the DS. problem the parent does not add the DS.
In the event this protocols and its associated authentication
mechanism does not address the Registrant's security requirements to
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. What checks are needed by parent?
The parent upon receiving a signal that it check the child for desire The parent upon receiving a signal that it check the child for desire
for DS record publication. The basic tests include, for DS record publication. The basic tests include,
1. The zone is signed 1. Is the zone is signed
2. The zone has a CDS signed by a KSK referenced in the current DS, 2. The zone has a CDS signed by a KSK referenced in the current DS,
referring to a at least one key in the current DNSKEY RRset 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 3. All the name-servers for the zone agree on the CDS RRset contents
Parents can have additional tests, defined delays, queries over TCP, Parents can perform additional tests, defined delays, queries over
and even ask the DNS Operator to prove they can add data to the zone, TCP, ensure zone delegation best practice as per
or provide a code that is tied to the affected zone. The protocol is [I-D.wallstrom-dnsop-dns-delegation-requirements] and even ask the
partially-synchronous, i.e. the server can elect to hold connection DNS Operator to prove they can add data to the zone, or provide a
open until the operation has concluded or it can return that it code that is tied to the affected zone. The protocol is partially-
received the request. It is up to the child to monitor the parent synchronous, i.e. the server can elect to hold connection open until
for completion of the operation and issue possible follow-up calls. 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. OP-3-DNS-RR RESTful API 4. Third Party DNS operator to Registrars/Registries RESTful API
The specification of this API is minimalist, but a realistic one. The specification of this API is minimalist, but a realistic one.
Question: How to respond if the party contacted is not ALLOWED to
make the requested change? Registry Lock mechanisms that prevents domain hijacking block domains
prevent certain attributes in the registry to be changed. This API
may be denied access to change the DS records for domains that are
Registry Locked (HTTP Status code 401).
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, for the API SHOULD be provided over addresses the needs. In general, the API SHOULD be provided over
TLS-protected transport (e.g., HTTPS) or VPN. TLS-protected transport (e.g., HTTPS) or VPN.
4.2. Authorization 4.2. Authorization
Authorization is out of scope of this document. The CDS records Authorization is outside the scope of this document. The CDS records
present in the zone file are indications of intention to sign/unsign/ present in the zone file are indications of intention to sign/unsign/
update the DS records of the domain in the parent zone. This means update the DS records of the domain in the parent zone. This means
the proceeding of the action is not determined by who issued the the proceeding of the action is not determined by who issued the
request. Therefore, authorization is out of the scope. Registries request. Therefore, authorization is out of scope. Registries and
and registrars who plan to provide this service can, however, registrars who plan to provide this service can, however, implement
implement their own policy such as IP white listing, API key, etc. their own policy such as IP white listing, API key, etc.
4.3. Base URL Locator 4.3. Base URL Locator
The base URL for registries or registrars who want to provide this The base URL for registries or registrars who want to provide this
service to DNS Operators can be made auto-discoverable as an RDAP service to DNS Operators can be made auto-discoverable as an RDAP
extension. extension.
4.4. CDS resource 4.4. CDS resource
Path: /domains/{domain}/cds {domain}: is the domain name to be Path: /domains/{domain}/cds {domain}: is the domain name to be
skipping to change at page 7, line 5 skipping to change at page 7, line 17
Either the CDS/CDNSKEY or the DNSKEY can be used to create the DS Either the CDS/CDNSKEY or the DNSKEY can be used to create the DS
record. Note: entity expecting CDNSKEY is still expected accept the record. Note: entity expecting CDNSKEY is still expected accept the
/cds command. /cds command.
4.4.1.2. Response 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 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 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) 4.4.2. Removing a DS (turn off DNSSEC)
4.4.2.1. Request 4.4.2.1. Request
Syntax: DELETE /domains/{domain}/cds Syntax: DELETE /domains/{domain}/cds
A null CDS or CDNSKEY record mean the entire DS RRset must be
removed.
4.4.2.2. Response 4.4.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 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.4.3. DS Maintenance (Key roll over) 4.4.3. DS Maintenance (Key roll over)
4.4.3.1. Request 4.4.3.1. Request
Syntax: PUT /domains/{domain}/cds Syntax: PUT /domains/{domain}/cds
Maintenance activities are performed based on the CDS available in
the child zone. DS records may be added, removed. But the entire DS
RRset must not be deleted.
4.4.3.2. Response 4.4.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 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.5. Tokens resource 4.5. Tokens resource
Path: /domains/{domain}/tokens {domain}: is the domain name to be Path: /domains/{domain}/tokens {domain}: is the domain name to be
operated on operated on
skipping to change at page 8, line 30 skipping to change at page 9, line 11
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.6. Customized Error Messages
Service providers can provide a customized error message in the Service providers can provide a customized error message in the
response body in addition to the HTTP status code defined in the response body in addition to the HTTP status code defined in the
previous section. previous section.
This can include an Identifiying number/string that can be used to This can include an Identifying number/string that can be used to
track the requests. track the requests.
#Using the definitions This section at the moment contains comments #Using the definitions This section at the moment contains comments
from early implementers from early implementers
4.7. How to react to 403 on POST cds 4.7. How to react to 403 on POST cds
The basic reaction to a 403 on POST /domains/{domain}/cds is to issue The basic reaction to a 403 on POST /domains/{domain}/cds is to issue
POST /domains/{domain}/tokens command to fetch the challenge to POST /domains/{domain}/tokens command to fetch the challenge to
insert into the zone. insert into the zone.
5. Security considerations 5. Security considerations
Supplying the DS record as proof of control is not realistic since
the domain is already publicly signed and the CDS/DS is readily
available.
Open question:?? JL?: It is not recommended the protocol be used with
high profile domains such as TLDs and governments that are DNS
operators. This protocol is meant to allow third party DNS operator
to submit the initial DS in a trusted manner without involving the
registrant.
This protocol should increase the adoption of DNSSEC and get more
zones to become validated thus overall the security gain outweighs
the possible drawbacks.
TBD This will hopefully get more zones to become validated thus TBD This will hopefully get more zones to become validated thus
overall the security gain out weights the possible drawbacks. overall the security gain out weights the possible drawbacks.
risk of takeover ? risk of validation errors < declines transfer risk of takeover ? risk of validation errors < declines transfer
issues issues
6. IANA Actions 6. IANA Actions
URI ??? TBD URI ??? TBD
7. Internationalization Considerations 7. Internationalization Considerations
This protocol is designed for machine to machine communications This protocol is designed for machine to machine communications
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-dnsop-maintain-ds] [I-D.ietf-dnsop-maintain-ds]
Gu[eth]mundsson, O. and P. Wouters, "Managing DS records Gudmundsson, O. and P. Wouters, "Managing DS records from
from parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain- parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-03
ds-00 (work in progress), December 2015. (work in progress), June 2016.
[I-D.wallstrom-dnsop-dns-delegation-requirements]
Wallstrom, P. and J. Schlyter, "DNS Delegation
Requirements", draft-wallstrom-dnsop-dns-delegation-
requirements-00 (work in progress), February 2016.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. <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>.
skipping to change at page 10, line 7 skipping to change at page 11, line 7
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>. <http://www.rfc-editor.org/info/rfc6690>.
[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. Version 03 A.1. Regex versio 01
Rewrote Abstract and Into (MP) Introduced code 401 when changes are
not allowed Text edits and clarifications.
A.2. Regex version 00
Working group document same as 03, just track changed to standard
A.3. Version 03
Clarified based on comments and questions from early implementors Clarified based on comments and questions from early implementors
A.2. Version 02 A.4. Version 02
Reflected comments on mailing lists Reflected comments on mailing lists
A.3. Version 01 A.5. Version 01
This version adds a full REST definition this is based on suggestions This version adds a full REST definition this is based on suggestions
from Jakob Schlyter. from Jakob Schlyter.
A.4. Version 00 A.6. Version 00
First rough version First rough version
Authors' Addresses Authors' Addresses
Jacques Latour Jacques Latour
CIRA CIRA
Email: jacques.latour@cira.ca Email: jacques.latour@cira.ca
 End of changes. 41 change blocks. 
90 lines changed or deleted 141 lines changed or added

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