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 tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:



regext mailing list


regext mailing list

Reply via email to