Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

Paul Wouters <> Wed, 22 June 2022 12:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2487DC15AE28 for <>; Wed, 22 Jun 2022 05:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JIBrdULfrwau for <>; Wed, 22 Jun 2022 05:40:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 978C4C15AAFE for <>; Wed, 22 Jun 2022 05:40:19 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4LSjds0MF2zq5; Wed, 22 Jun 2022 14:40:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1655901617; bh=eSMSHwwTx1uXDiByKMFz37xxSFxfrBbpy1pIFsSnziU=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=mjS472ltihRbSTVGTDzre+VDJFoAg7G4oOvwptksa2ws6aUCFGCNYEB/Svrow7NiX Y9sJvTLHWIlrVWISNlKy/EpC2hP9kj2d/hBB6XVOjrektTtydsa9ZUHEFiPlAktILO zcL6Ry8Ksvld4ZqBjPzJcFtA6uQpixqL3sgJZPd0=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id lISUb7Sr5pPG; Wed, 22 Jun 2022 14:40:15 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Wed, 22 Jun 2022 14:40:15 +0200 (CEST)
Received: from (unknown []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 80530395141; Wed, 22 Jun 2022 08:40:14 -0400 (EDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-72984CCF-F575-4C8C-A319-0F9C4C9BAF2F
Content-Transfer-Encoding: 7bit
From: Paul Wouters <>
Mime-Version: 1.0 (1.0)
Date: Wed, 22 Jun 2022 08:40:10 -0400
Message-Id: <>
References: <>
In-Reply-To: <>
X-Mailer: iPhone Mail (19F77)
Archived-At: <>
Subject: Re: [DNSOP] CDS Bootstrapping for vanity DNS servers
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jun 2022 12:40:24 -0000

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.


Sent using a virtual keyboard on a phone

> On Jun 21, 2022, at 23:30, wrote:
>>> On 22 Jun 2022, at 00:07, John Levine <> wrote:
>>> It appears that  <> said:
>>>> -=-=-=-=-=-
>>>> Hi.
>>>> During a meeting today of ROW (, the I-D on CDS bootstrapping by using a DNSSEC-signed name at name server
>>>> zone ( 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 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: .
> 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