Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

George Michaelson <ggm@algebras.org> Wed, 22 June 2022 03:36 UTC

Return-Path: <ggm@algebras.org>
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 64CB5C14F74E for <dnsop@ietfa.amsl.com>; Tue, 21 Jun 2022 20:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs7VBPabJxTU for <dnsop@ietfa.amsl.com>; Tue, 21 Jun 2022 20:36:37 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED08C14CF06 for <dnsop@ietf.org>; Tue, 21 Jun 2022 20:36:36 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id c2so25645875lfk.0 for <dnsop@ietf.org>; Tue, 21 Jun 2022 20:36:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+oX2fgS0AsR1P9kN3y4ECuqKEXQjrjud4rHfo1BjlWU=; b=lmPLP7nwVcRzhuWDUjbNBoadv91xVMqJ4bzMMUk4y7jFd9Hsm2dgCbxVJaZ/nva5jk AcINQemegerF/1lV9e2ZyoAA3VBHUXvrwnxJtiUsTEqvgrrmE82mLSMWV5rcmOogziyH XgNkdSBbAnhbIfVkzAEDRmUpq+2Ibe0ewEOiC/4Wk09ZkU+DRewI9LSSnQwJ8MquSbuF IW8BIJocCnUYQJYGnZrNdwWfZTZS9X0b4yQMNL1VCkimY4Yps5ys2V02zRPS7BZtDucX n1Nujy8zhfGdd8lxYNCUl5rVH+43yGlrcuen2dfqaEWWaiwSxASGG3rtbf+lEK/QHdoa qOxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+oX2fgS0AsR1P9kN3y4ECuqKEXQjrjud4rHfo1BjlWU=; b=a9g4jwAen96oEuQZvhbPKWjabwdRjOBRPgXgAReARj6TgU3zY5seUtBhvHIsgnpxc7 f6UhV/TlRa8MAIoXBRZF8e4rRMb6qhjdVsknHjJv73sbzb7oCd0idB/z9nmxqCPZdyGS SDIrOU8RQ6pr15P9Q8b3XXDQ1kYi8O+ZiG7h04lron+7/z/GWgavzeARqSLELiVumLoC Qe/00Xs15ml1fvE0x1JmiFkxgUFjXQs9F3kTJT9Ki7vsrXzyR5LUJDS1J0M9mxE0+SSP 7SdUwuhmccXnjKiKQ8bdef3idluvkpmcVvBbkdGcAFby7EHyyQAXHom2r+rF00Fc7sFP E3dg==
X-Gm-Message-State: AJIora/gU7xjzS0oiGdrj8SpF3WKB94GIm/DOXAge36Mb0ueYTZ9Ergl Z+Nfr/22bOiW+1tywavEpwl76bMNrHHFxWTPDw3G6/KQpTs=
X-Google-Smtp-Source: AGRyM1v0945Jx3ulcnz0YtB+L1cuTO50jYMMgNVRJgJcwy303xVD/DcX+HYX5tD9m6pz8uUqCU/cwdIHQ3x4RNkh+Bw=
X-Received: by 2002:a05:6512:3045:b0:479:5a22:3231 with SMTP id b5-20020a056512304500b004795a223231mr899189lfb.451.1655868994877; Tue, 21 Jun 2022 20:36:34 -0700 (PDT)
MIME-Version: 1.0
References: <20220622030749.83A5343F6B20@ary.qy> <26B807C3-D9E3-4D00-A20E-D3A1DBF6B7D0@nic.br>
In-Reply-To: <26B807C3-D9E3-4D00-A20E-D3A1DBF6B7D0@nic.br>
From: George Michaelson <ggm@algebras.org>
Date: Wed, 22 Jun 2022 13:36:23 +1000
Message-ID: <CAKr6gn03E84BAqrx7_U8QgZhLhBbrbvuc0jcMp3xVOPwfyuoog@mail.gmail.com>
To: rubensk=40nic.br@dmarc.ietf.org
Cc: John Levine <johnl@taugh.com>, dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TVxyuwGxVPycvuV7CehShF4_Cm4>
Subject: Re: [DNSOP] CDS Bootstrapping for vanity DNS servers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 22 Jun 2022 03:36:41 -0000

As a point of information, All the parent zones (the /8 and /12 RIR
delegations in in-addr.arpa and ip6.arpa) are now signed. Or should
be. it is possible a couple of stand-out /8 holdings aren't but thats
resolvable at some pain.

The problem would be that for CDN hosting instances of DNS, the uplift
of the credentials for a specific NS instance "inside" any given
sub-delegation demands that parent space itself be signed, and that
they offer some mechanism to allow NS instances to associate their
info with the record.

Its the classic "how do I make sure my registrar follows spec and
supports this" but instead of being about gTLD and ccTLD its moved
into the un-regulated in-addr and ip6 .arpa subspaces, where the
registrar in question is an address delegate.

Outside of the people who already have mechanisms to do things (the
gTLD and ccTLD and the big players and historically vested ISPs and
tier-1s) I hazard that few DNS lie in self managed integral address
ranges, and most DNS lies in managed, rented, sub-allocated address
space.

-George

On Wed, Jun 22, 2022 at 1:29 PM <rubensk=40nic.br@dmarc.ietf.org> wrote:
>
>
>
> On 22 Jun 2022, at 00:07, John Levine <johnl@taugh.com> wrote:
>
> It appears that  <rubensk@nic.br> said:
>
> -=-=-=-=-=-
>
>
> Hi.
>
> During a meeting today of ROW (https://regiops.net), the I-D on CDS bootstrapping by using a DNSSEC-signed name at name server
> zone (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/) was discussed.
> In that discussion, it was mentioned that the current draft only supports out-of-bailiwick name servers; I replied that the
> same principle could be applied to in-bailiwick name server by usage of the reverse DNS zones for IPv4 and IPv6.
>
>
> Urrgh. In principle, you can put anything you want in a reverse zone.
> (Send mail to johnl@18.183.57.64.in-addr.arpa. and it'll work.)
>
>
> That's my recollection as well, but as the saying goes, code is law. Although in this case only registry/registrar and DNS operator are required to interoperate for the bootstrapping process.
>
> In practice, I doubt that enough reverse zones are signed or that the
> provisoning crudware that people use for reverse zones would work
> often enough to be worth trying to do this. I did some surveys of
> zones and found that in-bailiwick NS are quite uncommon, only a few
> percent of the ones in large gTLDs.
>
>
> I don't expect the IP space used for DNS servers to be managed thru an IPAM system of sorts. But if one is used, it's unlikely they provision a zone-cut as required in the draft.
>
> The prevalence among the overall DNS system is indeed low, but I wonder what % this represents within services that allow all of DNSSEC, CDS Bootstrapping and in-bailiwick DNS servers, like Business and Enterprise plans in Cloudflare: https://developers.cloudflare.com/dns/additional-options/custom-nameservers/ .
>
>
> Or if supporting this type of DNS servers can help the adoption of this draft for the 99.9% use case of out-of-bailiwick servers. If not, we could be adding a new piece to the DNS Camel...
>
>
>
> Rubens
>
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop