[regext] Unsolicited comments on ...dnsoperator-to-rrr-protocol-01.txt

[Edward Lewis <[e-mail]>]

I've been meaning to read this for a while and got time to do so today.

Realize that this is still early, my comments are meant to try to drive more detail in the process.

If you /usr/bin/more the file and search for "^[^#]" you'll find my comments.

(I'd use vi and "/^[^#]" but I'm that old and won't assume anyone else would read it that way.)

-----Cut Here-----

## regext                                                         J. Latour
## Internet-Draft                                                      CIRA
## Intended status: Standards Track                          O. Gudmundsson
## Expires: January 8, 2017                                Cloudflare, Inc.
##                                                               P. Wouters
##                                                                  Red Hat
##                                                              M. Pounsett
##                                                    Rightside Group, Ltd.
##                                                             July 7, 2016
## 
## 
##        Third Party DNS operator to Registrars/Registries Protocol
##           draft-ietf-regext-dnsoperator-to-rrr-protocol-01.txt
## 
## Abstract
## 
##    There are several problems that arise in the standard
##    Registrant/Registrar/Registry model when the operator of a zone is
##    neither the Registrant nor the Registrar for the delegation.
##    Historically the issues have been minor, and limited to difficulty
##    guiding the Registrant through the initial changes to the NS records
##    for the delegation.  As this is usually a one time activity when the
##    operator first takes charge of the zone it has not been treated as a
##    serious issue.
## 
##    When the domain on the other hand uses DNSSEC it necessary to make
##    regular (sometimes annual) changes to the delegation, in order to
##    track KSK rollover, by updating the delegation's DS record(s).  Under

Even more so, unplanned, urgent changes.

##    the current model this is prone to delays and errors.  Even when the
##    Registrant has outsourced the operation of DNS to a third party the
##    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
##    through an authenticated channel can be used to establish the DNSSEC
##    Initial Trust (to turn on DNSSEC or bootstrap DNSSEC).  Once DNSSEC
##    trust is established this channel can be used to trigger maintenance
##    of delegation records such as DS, NS, and glue records.  The protocol
##    is kept as simple as possible.
## 
## Latour, et al.           Expires January 8, 2017                [Page 1]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## Status of This Memo
## 
##    This Internet-Draft is submitted in full conformance with the
##    provisions of BCP 78 and BCP 79.
## 
##    Internet-Drafts are working documents of the Internet Engineering
##    Task Force (IETF).  Note that other groups may also distribute
##    working documents as Internet-Drafts.  The list of current Internet-
##    Drafts is at http://datatracker.ietf.org/drafts/current/.
## 
##    Internet-Drafts are draft documents valid for a maximum of six months
##    and may be updated, replaced, or obsoleted by other documents at any
##    time.  It is inappropriate to use Internet-Drafts as reference
##    material or to cite them other than as "work in progress."
## 
##    This Internet-Draft will expire on January 8, 2017.
## 
## Copyright Notice
## 
##    Copyright (c) 2016 IETF Trust and the persons identified as the
##    document authors.  All rights reserved.
## 
##    This document is subject to BCP 78 and the IETF Trust's Legal
##    Provisions Relating to IETF Documents
##    (http://trustee.ietf.org/license-info) in effect on the date of
##    publication of this document.  Please review these documents
##    carefully, as they describe your rights and restrictions with respect
##    to this document.  Code Components extracted from this document must
##    include Simplified BSD License text as described in Section 4.e of
##    the Trust Legal Provisions and are provided without warranty as
##    described in the Simplified BSD License.
## 
## Table of Contents
## 
##    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
##    2.  Notional Conventions  . . . . . . . . . . . . . . . . . . . .   4
##      2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
##      2.2.  RFC2119 Keywords  . . . . . . . . . . . . . . . . . . . .   4
##    3.  What is the goal? . . . . . . . . . . . . . . . . . . . . . .   4
##      3.1.  Why DNSSEC? . . . . . . . . . . . . . . . . . . . . . . .   4
##      3.2.  How does a child signal its parent it wants DNSSEC Trust
##            Anchor? . . . . . . . . . . . . . . . . . . . . . . . . .   5
##      3.3.  What checks are needed by parent? . . . . . . . . . . . .   5
##    4.  Third Party DNS operator to Registrars/Registries RESTful API   6
##      4.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .   6
##      4.2.  Authorization . . . . . . . . . . . . . . . . . . . . . .   6
##      4.3.  Base URL Locator  . . . . . . . . . . . . . . . . . . . .   6
##      4.4.  CDS resource  . . . . . . . . . . . . . . . . . . . . . .   6
## 
## 
## 
## Latour, et al.           Expires January 8, 2017                [Page 2]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
##        4.4.1.  Initial Trust Establishment (Enable DNSSEC
##                validation) . . . . . . . . . . . . . . . . . . . . .   6
##        4.4.2.  Removing a DS (turn off DNSSEC) . . . . . . . . . . .   7
##        4.4.3.  DS Maintenance (Key roll over)  . . . . . . . . . . .   8
##      4.5.  Tokens resource . . . . . . . . . . . . . . . . . . . . .   8
##        4.5.1.  Setup Initial Trust Establishment with Challenge  . .   8
##      4.6.  Customized Error Messages . . . . . . . . . . . . . . . .   9
##      4.7.  How to react to 403 on POST cds . . . . . . . . . . . . .   9
##    5.  Security considerations . . . . . . . . . . . . . . . . . . .   9
##    6.  IANA Actions  . . . . . . . . . . . . . . . . . . . . . . . .   9
##    7.  Internationalization Considerations . . . . . . . . . . . . .  10
##    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
##      8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
##      8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
##    Appendix A.  Document History . . . . . . . . . . . . . . . . . .  11
##      A.1.  Regex versio 01 . . . . . . . . . . . . . . . . . . . . .  11
##      A.2.  Regex version 00  . . . . . . . . . . . . . . . . . . . .  11
##      A.3.  Version 03  . . . . . . . . . . . . . . . . . . . . . . .  11
##      A.4.  Version 02  . . . . . . . . . . . . . . . . . . . . . . .  11
##      A.5.  Version 01  . . . . . . . . . . . . . . . . . . . . . . .  11
##      A.6.  Version 00  . . . . . . . . . . . . . . . . . . . . . . .  11
##    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11
## 
## 1.  Introduction
## 
##    Why is this needed?  DNS registration systems today are designed
##    around making registrations easy and fast.  After the domain has been
##    registered there are really three options on who maintains the DNS
##    zone that is loaded on the "primary" DNS servers for the domain this
##    can be the Registrant, Registrar, or a third party DNS Operator.
## 
##    Unfortunately the ease to make changes differs for each one of these
##    options.  The Registrant needs to use the interface that the
##    registrar provides to update NS and DS records.  The Registrar on the
##    other hand can make changes directly into the registration system.
##    The third party DNS Operator on the hand needs to go through the
##    Registrant to update any delegation information.
## 
##    Current system does not work well, there are many types of failures
##    have been reported and they have been at all levels in the
##    registration model.
## 
##    The failures result either inability to use DNSSEC or in validation
##    failures that case the domain to become invalid and all users that
##    are behind validating resolvers will not be able to to access the
##    domain.
## 
## 
## 
## 
## 
## Latour, et al.           Expires January 8, 2017                [Page 3]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
##    The goal of this document is to create an automated interface that
##    will reduce the friction in maintaining DNSSEC delegations.
## 
## 2.  Notional Conventions
## 
## 2.1.  Definitions
## 
##    For the purposes of this draft, a third-party DNS Operator is any DNS
##    Operator responsible for a zone where the operator is neither the
##    Registrant nor the Registrar of record for the delegation.
## 
##    Uses of the word 'Registrar' in this document may also be applied to
##    resellers: an entity that sells delegations through a registrar with
##    whom the entity has a reseller agreement.
## 
## 2.2.  RFC2119 Keywords
## 
##    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
##    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
##    document are to be interpreted as described in [RFC2119].
## 
## 3.  What is the goal?
## 
##    The primary goal is to have a protocol to establish a secure chain of
##    trust that involves parties that are not in the traditional RRR EPP
##    model, or when EPP is not used.

I don't think the Extensible Provisioning Protocol [STD 69] should be called
out specifically because it makes it sound as if the problem domain depends
on EPP being in use.  How the registrar communicates with the registry isn't
an important factor.

A better term would be the shared registry model (I'd have to find a reference) which describes a registry as a centralized zone manager working with separate
registrars and other agents that compete to update the registry at the behest
of registrants, who in the end control the delegated space.

(Sorry, if I'm blathering on.  All I'm writing is a way to describe the
problem space, but that isn't at issue.  I'm just trying to make sure that
the description avoids confusion.

## 
##    In the general case there should be a way to find the right
##    Registrar/Registry entity to talk to, but it does not exist.  Whois[]
##    is the natural protocol to carry such information but that protocol
##    but is unreliable and hard to parse.  Its proposed successor RDAP
##    [RFC7480] has yet be deployed on most TLD's.

I'd list this as problem area #1 - a DNS operator cannot easily and scalably
identify the registrar (registration agent?) for a domain name it is operating.
Thus the DNS operator has to fallback to relying on the registrant (as customer)
of the services.

...This can open up a question...how does the DNS operator know if their
customer is the registered owner of a domain?  I was aware of this when I was
in that position, but this really doesn't matter all that much.  I, in the
spirit of testing, loaded many illegitmate zones on my service but since I
had to delegations pointing to me, no one noticed.  But there are times when
this might matter (like two customers claiming the same domain).

## 
##    The preferred communication mechanism is to use is to use a REST
##    [RFC6690] call to start processing of the requested delegation
##    information.

Having not yet read the rest (no pun intended) yet, I like this approach.  The
problems with earlier attempts to solve this stemmed from trying to stay in
band (that is over port 53), which led to scaling problems.  Everything else
could work out, but having also seen this from a large registry angle, knowing
when to "pull the trigger" is impossible.

## 
## 3.1.  Why DNSSEC?
## 
##    DNSSEC [RFC4035] provides data authentication for DNS answers, having
##    DNSSEC enabled makes it possible to trust the answers.  The biggest
##    obstacle in DNSSEC adoption is the initial configuration of the
##    DNSSEC domain trust anchor at the parent, the DS record.
## 

I don't think you need section 3.1 in the draft.  Perhaps in other material.

## 
## 
## 
## 
## 
## 
## 
## Latour, et al.           Expires January 8, 2017                [Page 4]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
## 3.2.  How does a child signal its parent it wants DNSSEC Trust Anchor?
## 

Personal terminology quibble.

A trust anchor is a data structure in a DNSSEC validator, it is what the
operator of the validator has placed faith in, trust has been granted with
no more proof.

A secure entry point is what is signified in a DS resource record, it is
what the child zone owner has idicated to the parent as a what to extend
DNSSEC downward into the child, represented by a hash of a DNSKEY resource
record.

(You don't do this far, but to keep hammering because this is on my mind for
other reasons - A secure entry point can be a KSK, ZSK or a Common Signing Key.
Those terms are for documentation and out-of-band key management.)

##    The child needs first to sign the domain, then the child can "upload"
##    the DS record to its parent.  The "normal" way to upload is to go
##    through registration interface, but that fails frequently.  The DNS

Let's be a bit cleared - "but that fails frequently" - lacks specificity.  I'd
go with "has proven to sucumb to operational errors in sufficient frequency
to be significant operational problem to the detriment of DNSSEC adoption."

Okay, too many big words, ... but.

##    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
##    publishing one of the special DNS records CDS and/or CDNSKEY[RFC7344]
##    and its proposed extension [I-D.ietf-dnsop-maintain-ds].
## 
##    Once the "parent" "sees" these records it SHOULD start acceptance
##    processing.  This document covers how to make the CDS records visible
##    to the right parental agent.
## 
##    This document and [I-D.ogud-dnsop-maintain-ds] argue that the
##    publication of CDS/CDNSKEY record is sufficient for the parent to
##    start the acceptance processing.  The main point is to provide
##    authentication thus if the child is in "good" state then the DS
##    upload should be simple to accept and publish.  If there is any
##    problem the parent does not add the DS.

IMHO, there's a need to distinguish points here.

First we need a scaleble mechanism.  Without that nothing matters.  Can this
draft describe a scaleable way for a registry operator or registry agent to
discover when the -maintain-ds- mechanism is to be exercised?

(The reason I mention registry agent is that in some cases the registry agent
may be the one maintaining the portion of the database where the DS records
are homed.  The heart of this is that there are at least two models of domain
name registration - "thick" and "thin" - and present, perhaps more.  Getting
into that goes beyond the scope of this work, suffice it to say that for
generality, the entity exercising this might be the registry or an agent of
the registry, which might be a registrar or reseller in some terminologies.)

Second, we need to describe the technique to confirm an update is to be enacted.
This includes sanity and security checks.  And what is done to prevent looping,
that is, reapplying an update once the request has been satisfied.

Third, there's policy.  There may be some non-technical aspects, like how to
undo a mistaken (hijacked?) update.

It's the last sentence that makes me wince.  I've seen (not meant to be
pejorative) statement that hand-wave cause grief down the line.

## 
##    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.

Caution: "Trust Anchor delegation" isn't a thing.

## 
## 3.3.  What checks are needed by parent?
## 
##    The parent upon receiving a signal that it check the child for desire
##    for DS record publication.  The basic tests include,
## 
##    1. Is the zone is signed
##    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
##    3. All the name-servers for the zone agree on the CDS RRset contents

What if the zone is signed with an algorithm not understood by the parent zone
operator?

What if the zone is signed with a common signing key and the child zone operator
does not set the SEP bit?  (An answer could be - they have to.)

What if the zone operator is having trouble with it's servers and can't get
them to agree?

I'm not throwing up road blocks, just questions that are hit in operations.  The
latter might be a zone admin trying to get back up after an event, so things
aren't as they ought to be.  This isn't the normal state of affairs - it's
probably appropriate to define a sunny day scenario and then leave hooks for
escalation for rainy day situations.

Failure to make explicit that some practices are for sunny days has caused
confusion when trying to map them into recovery scenarios.  E.g., RFC 5011's
Automated Updates is designed for normal rollovers, not for situations when
the existing key has been lost (deleted, crushed, stolen) and unable to sign the
revocation.  The process works, but only within a certain operational envelop.

## 
##    Parents can perform additional tests, defined delays, queries over
##    TCP, ensure zone delegation best practice as per
##    [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
## 
## 
## 
## Latour, et al.           Expires January 8, 2017                [Page 5]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
##    request.  It is up to the child to monitor the parent for completion
##    of the operation and issue possible follow-up calls.

I think this paragraph deserved expansion, if over time.  I can see some
testing done to establish credentials which are then used to make updates.

Consider this situation.  I'm running an on-line business.  I need to roll
the KSK because of an incident.  What can be done to speed time to recovery?
Can there be a pre-arranged credential?  Granted, there are many considerations,
and in some scenarios what would happen is a change in DNS operator anyway.

Probably needs some discussion and some operational data to consider, not
just document edits.  I don't know what is the common failure mode that would
call for a roll of a DS record.

## 
## 4.  Third Party DNS operator to Registrars/Registries RESTful API
## 
##    The specification of this API is minimalist, but a realistic one.
## 
##    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).

Should have a reference for Registry Lock.  It's possible a DNS'r will read
this and not have much familiarity with registration practices.

## 
## 4.1.  Authentication
## 
##    The API does not impose any unique server authentication
##    requirements.  The server authentication provided by TLS fully
##    addresses the needs.  In general, the API SHOULD be provided over
##    TLS-protected transport (e.g., HTTPS) or VPN.

It sounds like the API has to be provided over TLS...perhaps a MUST?

## 
## 4.2.  Authorization
## 
##    Authorization is outside the scope of this document.  The CDS records
##    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
##    the proceeding of the action is not determined by who issued the
##    request.  Therefore, authorization is out of scope.  Registries and
##    registrars who plan to provide this service can, however, implement
##    their own policy such as IP white listing, API key, etc.

I don't understand the previous paragraph.

The CDS records ought to be signed by the...etc.  "IP white listing, API key,
etc" leaves too much to the imagination.

## 
## 4.3.  Base URL Locator
## 
##    The base URL for registries or registrars who want to provide this
##    service to DNS Operators can be made auto-discoverable as an RDAP
##    extension.
## 
## 4.4.  CDS resource
## 
##    Path: /domains/{domain}/cds {domain}: is the domain name to be
##    operated on
## 
## 4.4.1.  Initial Trust Establishment (Enable DNSSEC validation)
## 
## 4.4.1.1.  Request
## 
##    Syntax: POST /domains/{domain}/cds
## 
##    A DS record based on the CDS record in the child zone file will be
##    inserted into the registry and the parent zone file upon the
## 
## 
## 
## Latour, et al.           Expires January 8, 2017                [Page 6]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
##    successful completion of such request.  If there are multiple CDS
##    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
##    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 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
##       challenge token.
## 
##    o  HTTP Status code 404 indicates the domain does not exist.
## 
##    o  HTTP Status code 500 indicates a failure due to unforeseeable
##       reasons.
## 
## 4.4.2.  Removing a DS (turn off DNSSEC)
## 
## 4.4.2.1.  Request
## 
##                    Syntax: DELETE /domains/{domain}/cds
## 
##    A null CDS or CDNSKEY record mean the entire DS RRset must be
##    removed.

What is the impact on opt-out at the parent?  I assume that once a delegation
no longer has a DS record, it is the parent's prerogative to exclude the
delegation from an NSEC3 ring (if NSEC3 is in use) or let it remain in.

Opt-out was defined with the idea that even non-DS'd delegations could be in
the ring but as far as I know, no tools or any operators include such
delegations in the ring.  I want to make sure we don't start to assume that
opt-out is only as tools have implemented it, unless we update the specs
(for Draft or Full Standard, what ever the next level would be).

## 
## 4.4.2.2.  Response
## 
##    o  HTTP Status code 200 indicates a success.
## 
##    o  HTTP Status code 400 indicates a failure due to validation.
## 
##    o  HTTP Status code 401 indicates an unauthorized resource access.
## 
##    o  HTTP Status code 404 indicates the domain does not exist.
## 
##    o  HTTP Status code 500 indicates a failure due to unforeseeable
##       reasons.
## 
## 
## 
## 
## 
## 
## 
## Latour, et al.           Expires January 8, 2017                [Page 7]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
## 4.4.3.  DS Maintenance (Key roll over)
## 
## 4.4.3.1.  Request
## 
##                      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.

I would refrain from assuming a DS change is due to a rollover.  Most likely,
but there's no need to assume the reason for a change unless the reason
impacts how the change is done.

## 
## 4.4.3.2.  Response
## 
##    o  HTTP Status code 200 indicates a success.
## 
##    o  HTTP Status code 400 indicates a failure due to validation.
## 
##    o  HTTP Status code 401 indicates an unauthorized resource access.
## 
##    o  HTTP Status code 404 indicates the domain does not exist.
## 
##    o  HTTP Status code 500 indicates a failure due to unforeseeable
##       reasons.
## 
## 4.5.  Tokens resource
## 
##    Path: /domains/{domain}/tokens {domain}: is the domain name to be
##    operated on

Might want to add some words on what a token is.  It's not entirely clear.

(I'd suggest something but I realize I'm not clear on this either.)

## 
## 4.5.1.  Setup Initial Trust Establishment with Challenge
## 
## 4.5.1.1.  Request
## 
##                    Syntax: POST /domains/{domain}/tokens
## 
##    A random token to be included as a _delegate TXT record prior
##    establishing the DNSSEC initial trust.

"Random" is probably not the correct adjective.  The token may be created
based on randomized inputs, but you need the correct token (define correct)
for any actions to occur, right?

## 
## 4.5.1.2.  Response
## 
##    o  HTTP Status code 200 indicates a success.  Token included in the
##       body of the response, as a valid TXT record
## 
##    o  HTTP Status code 404 indicates the domain does not exist.
## 
##    o  HTTP Status code 500 indicates a failure due to unforeseeable
##       reasons.
## 
## 
## 
## 
## 
## Latour, et al.           Expires January 8, 2017                [Page 8]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
## 4.6.  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
##    POST /domains/{domain}/tokens command to fetch the challenge to
##    insert into the zone.
## 
## 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.

I personally am nervous about establishing an initial state of security via
in-band methods, as well as maintaining security without consideration of
"forward secrecy"-ish issues.  I.e., I agree that you can't base anything on
the DS record - which is public data.  If the key it represents is poorly
secured and is compromised, then the DS is worthless in so many ways.

There are other means available, starting with the fact that the domain name
had to undergo a registration process.

## 
##    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.

I'll start with the comment that this is not a good idea to burn into a
protocol definition.  Separate intent from mechanism.

Operationally I think this would be bad.  I'd prefer that the security model
be rugged enough that high-profile domains would be willing to use this. If
I ran a high-profile domain I would be in the position of automating my
operations shop as much as possible as human error is the most likely cause
of avoidable disruptions.

http://wtop.com/dc/2016/08/dc-911-outage-caused-by-contractor-who-pulled-wrong-switch/

“Unfortunately because it was human error we weren’t prepared for it,” Holmes said.

I spun in my grave when I read that.

## 
##    This protocol should increase the adoption of DNSSEC and get more
##    zones to become validated thus overall the security gain outweighs
##    the possible drawbacks.

Vague - prevalence of DNSSEC signed zones.  To me adoption is better measured
in terms of validating resolvers. ;)

## 
##    TBD This will hopefully get more zones to become validated thus
##    overall the security gain out weights the possible drawbacks.

Hope is a strong word.  Can't hurt, but not sure this would be a driver.

## 
##    risk of takeover ? risk of validation errors < declines transfer
##    issues

Ok, I realize this is all draft and all, but still - what?

## 
## 6.  IANA Actions
## 
##    URI ??? TBD
## 
## 
## 
## 
## 
## 
## 
## 
## Latour, et al.           Expires January 8, 2017                [Page 9]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
## 7.  Internationalization Considerations
## 
##    This protocol is designed for machine to machine communications

What about printed/human-consumable error messages...keep that in mind.

## 
## 8.  References
## 
## 8.1.  Normative References
## 
##    [I-D.ietf-dnsop-maintain-ds]
##               Gudmundsson, O. and P. Wouters, "Managing DS records from
##               parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-03
##               (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.
##               Rose, "Protocol Modifications for the DNS Security
##               Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
##               <http://www.rfc-editor.org/info/rfc4035>.
## 
##    [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
##               DNSSEC Delegation Trust Maintenance", RFC 7344, DOI
##               10.17487/RFC7344, September 2014,
##               <http://www.rfc-editor.org/info/rfc7344>.
## 
## 8.2.  Informative References
## 
##    [I-D.ogud-dnsop-maintain-ds]
##               Gu[eth]mundsson, O. and P. Wouters, "Managing DS records
##               from parent via CDS/CDNSKEY", draft-ogud-dnsop-maintain-
##               ds-00 (work in progress), October 2015.
## 
##    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
##               Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
##               RFC2119, March 1997,
##               <http://www.rfc-editor.org/info/rfc2119>.
## 
##    [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
##               Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
##               <http://www.rfc-editor.org/info/rfc6690>.
## 
##    [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
##               Registration Data Access Protocol (RDAP)", RFC 7480, DOI
##               10.17487/RFC7480, March 2015,
##               <http://www.rfc-editor.org/info/rfc7480>.
## 
## 
## 
## Latour, et al.           Expires January 8, 2017               [Page 10]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
## Appendix A.  Document History
## 
## 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
## 
## A.4.  Version 02
## 
##    Reflected comments on mailing lists
## 
## A.5.  Version 01
## 
##    This version adds a full REST definition this is based on suggestions
##    from Jakob Schlyter.
## 
## A.6.  Version 00
## 
##    First rough version
## 
## Authors' Addresses
## 
##    Jacques Latour
##    CIRA
## 
##    Email: [e-mail]
## 
## 
##    Olafur Gudmundsson
##    Cloudflare, Inc.
## 
##    Email: [e-mail]
## 
## 
##    Paul Wouters
##    Red Hat
## 
##    Email: [e-mail]
## 
## 
## 
## 
## 
## Latour, et al.           Expires January 8, 2017               [Page 11]
##  
## Internet-Draft                  3-DNS-RRR                      July 2016
## 
## 
##    Matthew Pounsett
##    Rightside Group, Ltd.
## 
##    Email: [e-mail]
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## Latour, et al.           Expires January 8, 2017               [Page 12]