Hi Olafur. Some comments below. In "4.4.1. Initial Trust Establishment (Enable DNSSEC validation)" I'm concerned on having an "out-of-band" validation of the right DS/DNSKEY value. Using only the CDS record through DNS is weaker than current method, when there's an EPP from the registrar or a registrant confirmation through its domain control panel of the right key. I think it could be solved using this initial POST including in the restful API call the CDS/DS/DNSKEY or CDNSKEY value as a request parameter, which can be matched with DNS.
In "4.5.1. Setup Initial Establishment with Challenge", I'm wondering if the right method should be GET instead of POST. I'm not a REST expert, but I'd expect a read-only operation to be GET. Although its true that some registrar could associate the token in the moment of the call, also the registrar could have pre-generated tokens already associated with domains. So this call is a GET of that value. Also, I think it could have an "expiration datetime" in the response, after which the DNS operator should ask again for a new value. Regards, Hugo On 11:02 26/04, Olafur Gudmundsson wrote: > > This version is identical to version that was used for the call for adoption > the track was changed to Standards track. > > A version 01 is in the works and will be published soon. > > Olafur (for editors) > > > On Apr 26, 2016, at 11:01 AM, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Registration Protocols Extensions of the > > IETF. > > > > Title : Third Party DNS operator to Registrars/Registries > > Protocol > > Authors : Jacques Latour > > Olafur Gudmundsson > > Paul Wouters > > Matthew Pounsett > > Filename : draft-ietf-regext-dnsoperator-to-rrr-protocol-00.txt > > Pages : 10 > > Date : 2016-04-26 > > > > 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 for the > > Registrant in this situation to make regular (sometimes annual) > > changes to the delegation in order to track KSK rollover, by updating > > the delegation's DS record(s). Under the current model this is prone > > to Registrant error and significant delays. 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. > > > > 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. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-00 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > regext mailing list > > regext@ietf.org > > https://www.ietf.org/mailman/listinfo/regext > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext >
signature.asc
Description: PGP signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
