[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
- [DNSOP] Fwd: Adding DNS providers to the registra… Steve Crocker