Hi All,
CIRA developed a prototype to test the implementation of the DNS operator RRR protocol. There's a web interface, the API itself along with 5 test domains. The documentation and code is on GitHub: https://github.com/CIRALabs/DSAP The prototype itself is at http://dsap.ciralabs.ca/api, and the front end GUI http://dsap.ciralabs.ca/ (cira/dsap) (note: we spent way more time on the API than on the GUI) We're in the planning phase to put this in production at CIRA. Give it a try. Send feedback to d...@cira.ca<mailto:d...@cira.ca> Jacques ________________________________________ From: regext [regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>] on behalf of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>] Sent: Friday, July 08, 2016 11:01 AM To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> Cc: reg...@ietf.org<mailto:reg...@ietf.org> Subject: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-01.txt 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-01.txt Pages : 12 Date : 2016-07-08 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 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. 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnsoperator-to-rrr-protocol-01 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 reg...@ietf.org<mailto:reg...@ietf.org> https://www.ietf.org/mailman/listinfo/regext
