[DNSOP] Fwd: Adding DNS providers to the registration

Steve Crocker <steve@shinkuro.com> Sun, 19 January 2020 17:47 UTC

Return-Path: <steve@shinkuro.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D6E12002E for <dnsop@ietfa.amsl.com>; Sun, 19 Jan 2020 09:47:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shinkuro-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qizsf3fMgMli for <dnsop@ietfa.amsl.com>; Sun, 19 Jan 2020 09:47:38 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138C812002F for <dnsop@ietf.org>; Sun, 19 Jan 2020 09:47:38 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id cy15so27322537edb.4 for <dnsop@ietf.org>; Sun, 19 Jan 2020 09:47:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PD7oNhgPBWJtv2RWb5oUs0NLg9XUtO5lSEvi7Lg918o=; b=AkSVlY7NSXI2OGnWgvnRNGHlnB9hlHG+MdcmWOE7zN29SS/1mdvdcBFTu+jOaQyvj6 LhCSjNUNKRdVXEKhqKmbvjRc57wolPPgHjyohuW7+pBvyvZVHbxxf8rUFsNEeQSyW/r1 PErKHEjPVpW40tjuajPdNZ5F9t/GLZUL/FQ0iByZSr3vzJ5z7VXKTvlauTKV+HTt2F7q pwvGkjnJsRv3yrnMx0wm57mvIrj6dk0FHNAS4ooL2U8bcAlDSfDLLW6y05cHIYx+J2ap RsF95a7SU4jWL3WseuMF5ZQYP1otkZiMJgYb1uh/Ap35SlSEHy4HSfdvzPpc3dcilhow bSOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PD7oNhgPBWJtv2RWb5oUs0NLg9XUtO5lSEvi7Lg918o=; b=dXn60KKeAny54s5FWQnZb7LeLnU+IuTV0huTSECVtHwWYlJRxtQ7AGvdBjskKSxEjb LiVYctj8E1pYf3XY9821FfTK3dRE8JZCqbDAZ12w2VMzh2uGRIhlbnkvRgEqvfLfTnRH 9Urfc3+Nt8gleJKpGC+r0vSXRlq6v6ETEpe7M2x+74SVoPsHuv1KJGGdTyGCzgdbH5pn MFqG8D221fbjm32NeBw1qMIoqrSSJ3EAYAep2NPIpUPRCmdJNhZgFI0XGN0yVpVF26q7 PbZClmqB1n6wfDZx4VIZZFmUz5wfGGH3fGMhqZMMOZ2f+ObF9UxOrxlJTIvcOr/Jteij ONAA==
X-Gm-Message-State: APjAAAUTTAdouynLPElnC16GSfOox6C+kbp/AlfCD/0JqpqfZO8qycWt FZdcVEu2F5sBnrLrhb0We1IZyUieXYMA29JrG4SNAO/v
X-Google-Smtp-Source: APXvYqzUnQ5kUIJhQfcrrQ3xCvT54v4l6RsJ5a+GVXNgkWnN8AFSkAbFzGPIWrxgYsJcnIuSgeJQVf07398R5xoNqKk=
X-Received: by 2002:a50:f396:: with SMTP id g22mr14121050edm.336.1579456056583; Sun, 19 Jan 2020 09:47:36 -0800 (PST)
MIME-Version: 1.0
References: <CABf5zv+5Jo5gXUYZU3fVCoC4pWACGnJhd=qz=BrJvTM_45YDqw@mail.gmail.com>
In-Reply-To: <CABf5zv+5Jo5gXUYZU3fVCoC4pWACGnJhd=qz=BrJvTM_45YDqw@mail.gmail.com>
From: Steve Crocker <steve@shinkuro.com>
Date: Sun, 19 Jan 2020 12:47:25 -0500
Message-ID: <CABf5zv+hvn6_TQBCpZk9LM6QuOT8CXfAxXNaW8SdTnfd3SqEEQ@mail.gmail.com>
To: DNSSEC Coordination <dnssec-coord@elists.isoc.org>, dnsop <dnsop@ietf.org>, draft-ietf-dnsop-multi-provider-dnssec@ietf.org
Cc: DNSSEC Provisioning <dnssec-provisioning@shinkuro.com>
Content-Type: multipart/alternative; boundary="00000000000030f92e059c81c5fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TIxFF-uUdcYTCnxVEbeChLVkvps>
Subject: [DNSOP] Fwd: Adding DNS providers to the registration
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Jan 2020 17:47:41 -0000

Folks,

I've started a new mailing list for discussion of how to facilitate both DS
updates and cross-signing of zones when there are multiple DNS providers.
My tastes run toward "push/registrar" solutions for DS updates, but it's
certainly possible to use pull instead of push and registry instead of
registrar.  RFC 8078 is a pull/registry solution.  I believe some ccTLDs
are using it, but I have not seen any traction within the gTLD community.

I'm hoping one or more concrete proposals emerge from the interactions on
this list.  If they do, they will be submitted through the usual channels
for adoption.  (Some aspects will likely be appropriate for the IETF;
others for ICANN or other bodies.)  This activity is therefore a design
team.

The new mailing list is dnssec-provisioning@shinkuro.com  Comments are
welcome, as is membership on the list.

Thanks,

Steve


---------- Forwarded message ---------
From: Steve Crocker <steve@shinkuro.com>
Date: Sun, Jan 19, 2020 at 12:16 PM
Subject: Adding DNS providers to the registration
To: DNSSEC Provisioning <dnssec-provisioning@shinkuro.com>


I hereby propose that RDDS be extended to include the DNS provider(s).  I
believe that making DNS providers visible in the registration will make it
easier to automate both the upward movement of DS records to the registry
and coordination of cross-signing when there are multiple DNS providers.

DNS service is generally provided in one of three ways:

   - By the registrar.  This is probably the most common in terms of number
   of registrations, but not as common for larger registrants.
   - By the registrant as part of its internal operation.
   - By 3rd party DNS providers, e.g. Cloudflare, Dyn, et al.

Some registrants, particularly large registrants, will use multiple DNS
providers, so my proposal permits naming more than one DNS provider.

The intended functionality is for DNS providers to be able to push new DS
records upward whenever they roll the keys.  Accordingly, I'm expecting
that in addition to simply adding the name of the DNS provider to the
registration, the registrar will also have an access path for the DNS
provider to send it new DS records.  This leads to some design questions:

   1. How should DNS providers be designated?  The designation should be
   easy for the registrant to specify and not easily confused.

   2. The designation should serve as authorization for the DNS provider(s)
   to act on behalf of the registrant.

   3. In addition to updating the DS records, it  seems sensible to have
   the DNS provider specify the NS records as well.  What about glue records?

   4. Would DNS providers need to be qualified before being allowed to be
   included in the registration?  My quick thought is no because there are no
   barriers today in setting the NS records.

   5. Do we need a common naming scheme for DNS providers.  Perhaps
   something like _dns-provider.<domain name> would do the job.

It also seems to me that whenever a DNS provider is added to or removed
from a registration, both it and any other DNS providers receive
notification.  This should trigger the appropriate coordination.  To take
the easiest case, here's a sequence for the registration with a single 3rd
party DNS provider.

   1. Registrant registers the domain name with the registrar.
   2. Registrant contracts with the DNS provider for DNS service and
   populates the child zone.
   3. Registrant tells adds the name of the DNS provider to the
   registration.
   4. Registrar's process sends a notice to the DNS provider that it has
   been named as a DNS provider for the registrant's domain.
   5. DNS provider tells the registrar the list of nameservers, the DS
   record and any other details that may be needed.

Comments?  Suggestions?  Problems?

Thanks,

Steve