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.


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:

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


From: regext [regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>] on 
behalf of 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:   

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

   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:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 

Internet-Drafts are also available by anonymous FTP at:

regext mailing list
regext mailing list

regext mailing list

Reply via email to