Skip to main content

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

Document Type Expired Internet-Draft (regext WG)
Expired & archived
Authors Jacques Latour , Ólafur Guðmundsson , Paul Wouters , Matthew Pounsett
Last updated 2018-11-05 (Latest revision 2018-05-04)
Replaces draft-latour-dnsoperator-to-rrr-protocol
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Expired
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

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 uses DNSSEC it necessary to make regular (sometimes annual) changes to the delegation, updating DS record(s) in order to track KSK rollover. Under the current model this is prone to delays and errors, as the Registrant must participate in updates to DS records. This document describes a simple protocol that allows a third party DNS operator to: establish the initial chain of trust (bootstrap DNSSEC) for a delegation; update DS records for a delegation; and, remove DS records from a secure delegation. The DNS operator may do these things in a trusted manner, without involving the Registrant for each operation. This same protocol can be used by Registrants to maintain their own domains if they wish.

Authors

Jacques Latour
Ólafur Guðmundsson
Paul Wouters
Matthew Pounsett

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