Hi Pascal and all, It’s a prototype, we’re looking into making it production. It will interface directly to our .CA registry.
The API would have an ACL to enable DNS Operator to perform these functions on the domains they control. The web interface would be for individual registrant/DNS Operator, we need to add some more user access control mechanisms. Jacques On 2016-10-15, 12:21 PM, "Pascal Bouchareine" <pas...@gandi.net<mailto:pas...@gandi.net>> wrote: Hi Jacques, All, This is an interesting coincidence that we worked on an implementation of RRR last week too - I’ve started a small, poorly documented API here: https://github.com/kalou/rrr Gandi has rolled out the same service for experimentations - we support initial setup, updates, and removals too. If anyone is interested into experimenting with this contact me. I have two additional comments: - For DNSSEC availability check, and discovery, we’re using our (also exp.) RDAP service with a specific rel/href in the links section pointing to the CDS checker API endpoint - Is that production rollout @CIRA as a registrar, or the whole registry ? How do you plan on syncing DNSKEY information with registrars ? Best, Pascal On Oct 14, 2016, at 1:03 PM, Jacques Latour <jacques.lat...@cira.ca<mailto:jacques.lat...@cira.ca>> wrote: 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: regext@ietf.org<mailto:regext@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<http://tools.ietf.org/>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
