IETF Logo Mail Archive

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

rubensk@nic.br Wed, 22 June 2022 03:29 UTC

Return-Path: <rubensk@nic.br>
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 D2B53C14F74E for <dnsop@ietfa.amsl.com>; Tue, 21 Jun 2022 20:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 gwX6Z4pBubpb for <dnsop@ietfa.amsl.com>; Tue, 21 Jun 2022 20:29:50 -0700 (PDT)
Received: from mx.nic.br (mx.nic.br [200.160.4.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A30EC14F74C for <dnsop@ietf.org>; Tue, 21 Jun 2022 20:29:49 -0700 (PDT)
Received: from smtpclient.apple (unknown [191.19.224.122]) (Authenticated sender: rubens) by mx.nic.br (Postfix) with ESMTPSA id 8D5A6BD031; Wed, 22 Jun 2022 00:29:46 -0300 (-03)
From: rubensk@nic.br
Message-Id: <26B807C3-D9E3-4D00-A20E-D3A1DBF6B7D0@nic.br>
Content-Type: multipart/signed; boundary="Apple-Mail=_B476C465-F072-4551-A824-65C31F3D0F18"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Wed, 22 Jun 2022 00:29:45 -0300
In-Reply-To: <20220622030749.83A5343F6B20@ary.qy>
Cc: dnsop@ietf.org
To: John Levine <johnl@taugh.com>
References: <20220622030749.83A5343F6B20@ary.qy>
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Server: mx.nic.br
X-Spamd-Result: default: False [-4.50 / 15.00]; BAYES_HAM(-2.80)[99.15%]; SIGNED_PGP(-2.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; ASN(0.00)[asn:27699, ipnet:191.19.224.0/20, country:BR]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; NEURAL_HAM(-0.00)[-1.000]; FROM_NO_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; ARC_NA(0.00)[]
X-Rspamd-Queue-Id: 8D5A6BD031
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HCSYOrHpzYtdiV_ycJibcDX017s>
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:29:54 -0000


> 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/ <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

v2.23.0 | Report a Bug | By Email