Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

Peter Thomassen <> Mon, 27 June 2022 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56721C15AD22 for <>; Mon, 27 Jun 2022 10:54:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.782
X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C2nwIKPzmyBE for <>; Mon, 27 Jun 2022 10:54:54 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 344CAC15AAFA for <>; Mon, 27 Jun 2022 10:54:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NXDzSYYlmIjDZb/pY61ydxu06LwGAhjnamt3icq77Vo=; b=MXAbtIn8KmriXZRziskO0+yXjQ jVosfE8SA9DrKoWpGdjlb7rOxmRaO+gCrvJ9CGKNj4kOeAqwpjnuVIVnBRcxujE0m4UCPKWK/Oy7w uDbUKAOxYG35lZvfm3y950KIkdNOtgFJM6lbUUAC77bDJwWlj6rIEo9jALySXSe3iofvK1d9vD1GD z17n4Pa0WObbCGLZgj2Ll23mB6rYXR910IqrZYjShcb5Bm/dB6KjrWHd78Vd/Tpn/jU4pBMlqJamT jeMM5KfasF/q/MGEM3Mdc0q1yA/QD63aeiyJETijYMWJssaBKArwSPLOsMbEqY0PLf5fdscGR+GSY Qka6VOsA==;
Received: from ([2003:d4:6f3b:c9df:e5eb:45:e446:552f]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1o5swm-0005qj-Ej for; Mon, 27 Jun 2022 19:54:52 +0200
Message-ID: <>
Date: Mon, 27 Jun 2022 19:54:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
References: <> <>
From: Peter Thomassen <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Mon, 27 Jun 2022 17:54:58 -0000

On 6/22/22 14:40, Paul Wouters 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.

That's exactly right, DNS operators will in many cases not control the reverse zones of their NS IPs, especially when diversifying secondary operations across edge providers.

What's more: reverse-based signaling introduces additional trusted parties -- namely, the zone administrators of the reverse zone's parents. That will usually be some large-scale datacenter provider, the RIRs, up to the .arpa operator.

These are the same parties who have a say in how traffic to those IP addresses gets routed. If one of these actors mounted a DNSSEC spoofing attack on _signal.<reverse-zone>.arpa, an accompanying routing compromise may not pose much extra difficulty, but would allow for spoofing the child apex CDS/CDNSKEY records. This would enable injecting fake records at the child and having them fake-authenticated through the reverse zone.

In other words, reverse-based signaling introduces additional actors who are in an (at least somewhat) privileged position, potentially enabling them to undermine the whole protocol. This would change the trust model of the protocol (which is certainly conceivable; but it would have to be made explicit).

In contrast, the draft currently has no such actors at all; the registrant can choose all involved parties (including TLD registries). (Of course, there is always the root operator, but that is not specific to bootstrapping.)


>> 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
> _______________________________________________
> DNSOP mailing list

Like our community service? 💛
Please consider donating at

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525