Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

Bob Harold <rharolde@umich.edu> Wed, 22 June 2022 13:28 UTC

Return-Path: <rharolde@umich.edu>
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 D14BDC157B55 for <dnsop@ietfa.amsl.com>; Wed, 22 Jun 2022 06:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 L_1oqAv_jXCA for <dnsop@ietfa.amsl.com>; Wed, 22 Jun 2022 06:28:35 -0700 (PDT)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (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 B0DB7C14CF09 for <DNSOP@ietf.org>; Wed, 22 Jun 2022 06:28:35 -0700 (PDT)
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-3177f4ce3e2so139209517b3.5 for <DNSOP@ietf.org>; Wed, 22 Jun 2022 06:28:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q7SiEGdj/RItNZDW7HpqnQX1Il595aCaLM3FN1PF53E=; b=kA6Qf1JVEw6AsnPBJ7BBFshnJABZ24X2sxhYuHDyZAgREicr4HbamP1eYplT7uKcz5 84UxcaDnbr4Elo2C929gDR8d7MLLG8v5VXAsINiRw0ib2X6RgpdN8QJJW70QZuBonxZX QgzdknJzWIqicPfTSb+wtAXWulEKMqu84xFK4t8aXreSfAVpl1yl/wBi/peG+PExws8j lToGmhO0sXzOnnXqPFxkMPgz95MQBZZXaCX+TG9fOB4c54/b9Yztk6L25dmV0vupfYQt Jp5vE1BnJ5XX4PSdwahB32BLzTrDvsvJinUXGY20NNQBQWooxub/JGHY2mMGFpqZcPmm 6Z5A==
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; bh=Q7SiEGdj/RItNZDW7HpqnQX1Il595aCaLM3FN1PF53E=; b=eHT5/tqKXdISuIcTeEO1Cb34SibuXw2edNYSA2RYwK8unXVCBeyu9i2KeHamoqTfbk n6llvOpt3qYhK0lYK9+FKl8zW7h8FKeBh89Uyj+TFj891VHfafakfACaeiU22Xgw2tqw tBotN1WDXmbt4rfLvub4qVlFWPktSdkALLcOt6nmyfJbqA8ns1CT6j6Vyzw8BfecEGTb LlVbg1uqbWVTe4JQRj61RkQQ4mF32W6c8Kbay+TCQWZfa1StlYlr4WDUd/luBDSwXcoL aSJ0CmxF6+Hc0llIqH1Rl52IZP4F+SCnyPVnvSQVEy/wTIxQBn0eRMEjUdd8mO3w0Gkb w8bQ==
X-Gm-Message-State: AJIora8R6iHKpO5Pbkr/N4F+fn1KKaxk+BGdntFBa+p+fyj05S/0QAlt wFHjxbf6mkFEAk3KYgcrTpmCP8ofXE0kvO9PSi/Pqw==
X-Google-Smtp-Source: AGRyM1uP70/SZOk63GXmMjMQvvsKwSEKoZflH6A/2Q8RI9MPsLSCGojdkMK+LeU+3xejduufvDaX7LLPYUMkAIt9qAc=
X-Received: by 2002:a81:574c:0:b0:317:7c3a:45be with SMTP id l73-20020a81574c000000b003177c3a45bemr4330944ywb.316.1655904513405; Wed, 22 Jun 2022 06:28:33 -0700 (PDT)
MIME-Version: 1.0
References: <26B807C3-D9E3-4D00-A20E-D3A1DBF6B7D0@nic.br> <FA0E3F97-1D82-4E7F-89FB-012E0ACA6FED@nohats.ca>
In-Reply-To: <FA0E3F97-1D82-4E7F-89FB-012E0ACA6FED@nohats.ca>
From: Bob Harold <rharolde@umich.edu>
Date: Wed, 22 Jun 2022 09:28:22 -0400
Message-ID: <CA+nkc8DFMoYH2WjR0qVU8uU192x-k-9fDfBXviDzMOQkeB+EcQ@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: rubensk=40nic.br@dmarc.ietf.org, IETF DNSOP WG <DNSOP@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004dcf6e05e20950a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Rhcor-oCnAv6s9gIUGnAhb34Q-E>
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 13:28:39 -0000

Allowing the reverse zone method seems ok, but only if it is little extra
work, and does not hold up the rest.  As has been said, users can usually
get a third-party NS record, and the Registrars usually have a manual
method to add the first DS record.  This is a one-time event "per domain",
but once you have your first signed domain, then use an NS in that domain
to bootstrap the rest, so it really becomes a one-time event per
organization.

-- 
Bob Harold


On Wed, Jun 22, 2022 at 8:40 AM Paul Wouters <paul@nohats.ca> wrote:

> Unfortunately, the reverse zone is very often out of reach for those who
> use the IP range and trying to do classless reverse delegation (RFC 2317)
> for those who have less than a /24 is even harder to get.
>
> Paul
>
> Sent using a virtual keyboard on a phone
>
> On Jun 21, 2022, at 23:30, 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
>
>
>