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

The information below is for an old version of the document
Document Type Active Internet-Draft (regext WG)
Last updated 2016-05-06 (latest revision 2016-04-26)
Replaces draft-latour-dnsoperator-to-rrr-protocol
Stream IETF
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          J. Latour
Internet-Draft                                                      CIRA
Intended status: Standards Track                          O. Gudmundsson
Expires: October 28, 2016                               Cloudflare, Inc.
                                                              P. Wouters
                                                                 Red Hat
                                                             M. Pounsett
                                                   Rightside Group, Ltd.
                                                          April 26, 2016

       Third Party DNS operator to Registrars/Registries Protocol
          draft-ietf-regext-dnsoperator-to-rrr-protocol-00.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 for the
   Registrant in this situation 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 Registrant error and significant delays.  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.

   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.

Latour, et al.          Expires October 28, 2016                [Page 1]
Internet-Draft                  3-DNS-RRR                     April 2016

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 28, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Notional Conventions  . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  RFC2119 Keywords  . . . . . . . . . . . . . . . . . . . .   4
   3.  What is the goal? . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Why DNSSEC? . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  How does a child signal its parent it wants DNSSEC Trust
           Anchor?  The child  . . . . . . . . . . . . . . . . . . .   4
     3.3.  What checks are needed by parent? . . . . . . . . . . . .   5
   4.  OP-3-DNS-RR RESTful API . . . . . . . . . . . . . . . . . . .   5
     4.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Authorization . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Base URL Locator  . . . . . . . . . . . . . . . . . . . .   6
     4.4.  CDS resource  . . . . . . . . . . . . . . . . . . . . . .   6

Latour, et al.          Expires October 28, 2016                [Page 2]
Show full document text