Third Party DNS operator to Registrars/Registries Protocol
draft-ietf-regext-dnsoperator-to-rrr-protocol-01

The information below is for an old version of the document
Document Type Expired Internet-Draft (regext WG)
Last updated 2017-01-09 (latest revision 2016-07-08)
Replaces draft-latour-dnsoperator-to-rrr-protocol
Stream IETF
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state WG Document (wg milestone: Sep 2018 - Submit for publicati... )
Document shepherd No shepherd assigned
IESG IESG state Expired
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-ietf-regext-dnsoperator-to-rrr-protocol-01.txt

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.

Authors

Jacques Latour (jacques.latour@cira.ca)
Ólafur Guðmundsson (olafur+ietf@cloudflare.com)
Paul Wouters (paul@nohats.ca)
Matthew Pounsett (matt@conundrum.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)