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 <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 ?


> On Oct 14, 2016, at 1:03 PM, Jacques Latour <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 
> <https://github.com/CIRALabs/DSAP>
> The prototype itself is at http://dsap.ciralabs.ca/api 
> <http://dsap.ciralabs.ca/api>, and the front end GUI http://dsap.ciralabs.ca/ 
> <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 
>         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/
> <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 
> <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
> <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/ <ftp://ftp.ietf.org/internet-drafts/>
> _______________________________________________
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://www.ietf.org/mailman/listinfo/regext 
> <https://www.ietf.org/mailman/listinfo/regext>_______________________________________________
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://www.ietf.org/mailman/listinfo/regext 
> <https://www.ietf.org/mailman/listinfo/regext>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

regext mailing list

Reply via email to