Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

Peter Thomassen <peter@desec.io> Mon, 27 June 2022 17:40 UTC

Return-Path: <peter@desec.io>
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 843A4C15AAF4 for <dnsop@ietfa.amsl.com>; Mon, 27 Jun 2022 10:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.785
X-Spam-Level:
X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
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 7hUNMt0WcaDj for <dnsop@ietfa.amsl.com>; Mon, 27 Jun 2022 10:40:04 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [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 ietfa.amsl.com (Postfix) with ESMTPS id 2A4CDC15AAE6 for <dnsop@ietf.org>; Mon, 27 Jun 2022 10:40:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; 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=PMLr+LgjfPUW6xj6EgW7zF5FfMNAyrgH9riC211SyLQ=; b=Hn7hmHfX8UdDhqmzVNP8HxEUKD H5QltO/DZQFpk2Kcp0auVqkD9+1oCTTp6ews2XxnxnNHwSrngUdPmlo9EILIVizMTR4ghMtj/GwYH kkbv9AHmzsG8x7B0xUGlSylZ1HGOZ8XVIuE02Fg4V0nmQDVMWwxtpDQfCHSHAk3Ob5J4qJkccTgl9 W07alhhSskzjYnPFhooJqHe56uyPmj7Zq/hHw0jY4n2XxR5kluWUNhMi4QI6Ch4F3UzK8w5azgIrt adQzsmrGhjOukZSGaRlsoDrTT17Z9zwpC5WvygLP2SLu7j1N5F8MtAv+PSWuQ+Jy6Ml6lzJu48jgf cHJgzItQ==;
Received: from p200300d46f3bc9dfe5eb0045e446552f.dip0.t-ipconnect.de ([2003:d4:6f3b:c9df:e5eb:45:e446:552f]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1o5siO-0004bm-Sc for dnsop@ietf.org; Mon, 27 Jun 2022 19:40:01 +0200
Message-ID: <d71ce57c-ec26-3495-9c9a-62db911239ae@desec.io>
Date: Mon, 27 Jun 2022 19:40:00 +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
To: dnsop@ietf.org
References: <20220622030749.83A5343F6B20@ary.qy> <26B807C3-D9E3-4D00-A20E-D3A1DBF6B7D0@nic.br>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <26B807C3-D9E3-4D00-A20E-D3A1DBF6B7D0@nic.br>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yk3PXGbnLYFVeydUluKF5vmzVL4>
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: Mon, 27 Jun 2022 17:40:08 -0000

Hi Rubens,

On 6/22/22 05:29, rubensk=40nic.br@dmarc.ietf.org wrote:
>> On 22 Jun 2022, at 00:07, John Levine <johnl@taugh.com <mailto:johnl@taugh.com>> wrote:
>> 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 draft does not require a zone cut anywhere; it's merely a (normative-language) recommendation. Quoting from Section 4.1:

     Signaling Domains SHOULD be delegated as zones of their own, so that
     the Signaling Zone's apex coincides with the Signaling Domain (such
     as _signal.ns1.example.net).  While it is permissible for the
     Signaling Domain to be contained in a Signaling Zone of fewer labels
     (such as example.net), a zone cut ensures that bootstrapping
     activities do not require modifications of the zone containing the
     nameserver hostname.

Thinking about it, perhaps there's no reason for normative language here. If others agree, please let me know and I'll change to lowercase "should".

Thanks,
Peter

-- 
https://desec.io/