Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

Peter Thomassen <peter@desec.io> Mon, 27 June 2022 18:00 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 2B900C15791C; Mon, 27 Jun 2022 11:00:00 -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 7BNaYCSLMBNK; Mon, 27 Jun 2022 10:59:55 -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 3FDE9C14CF1A; Mon, 27 Jun 2022 10:59:55 -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:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: 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=BQRPXg6Hq2P0KUzC/J55FPs5PnGvlcLmMHpCyRKAbEw=; b=DZkM2AHPkSDu3vsRJmVNslguVq a4QY2RG3UZmCnfEi1iiChDuosjlfxw0gKv2Jh63iCehIS7tOtdX8CzIRZqlCGoJMiPJ/tU0f62c0Q MqLq8MMT45+L9hflIKL9HFl3PV60QunmIPsRW9+dzSUAbbmQjxn+Crd5kUCdFZ8j9ojHMbsIxemoM IydSj2U3MBawEYwCay0XkPRjkpY1oACqKOFLfEauF+q8IeX35v/3IJFSNAY0sR9rudv6O7m1exLbF 0p8B4PnwnTNElw05TNVEVA0xKpq1iDiHTlNIR5AaLY72A69TF1UHTyVFwXRJH2CF99aysVS+lPa6v 7RupH2fA==;
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 1o5t1d-0006Fb-EG; Mon, 27 Jun 2022 19:59:53 +0200
Message-ID: <37199180-413d-d07b-91a8-47729aeab02e@desec.io>
Date: Mon, 27 Jun 2022 19:59: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
To: Brian Dickson <brian.peter.dickson@gmail.com>, rubensk=40nic.br@dmarc.ietf.org
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
References: <84B820D1-5BF7-4C3A-8C4D-6D4CD1D554ED@nic.br> <CAH1iCirhF1ahe5OYYkFUzC6TjmeUa_O0VmEttTvCHgAgv+a0GA@mail.gmail.com>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <CAH1iCirhF1ahe5OYYkFUzC6TjmeUa_O0VmEttTvCHgAgv+a0GA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OHpAmoQ9Aft9A2ZxRd0cIiQgOMU>
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 18:00:00 -0000


On 6/22/22 08:36, Brian Dickson wrote:
> 
> The whole point of the bootstrap mechanism is to onboard the /initial/ DS record for a particular domain securely.
> Once the initial DS is present, there is no further need for bootstrap.
> For a single domain, the only purpose of doing what you propose for a "vanity" name server name, is to accomplish a one-shot action.
> 
> The use of some (any) third party DNS operator whose infrastructure zone(s) is/are signed, for the purposes of doing the bootstrap, followed by migrating the signed zone to another set of name servers securely (e.g. via the multi-signer mechanisms, or via setting the zone up as a signed AXFR from a hidden master), would achieve the same result without any new proposals or implementations required. That would be two steps instead of one, but only at the time of the initial DS. Once that DS is onboard at the parent domain, the bootstrap operator is no longer involved.

It's even more simple: You don't need to do any multi-signer stuff, because keys don't change.

If the DNS operator for your domain example.com has out-of-bailiwick nameservers

	ns1.provider.net
	ns2.provider.net

with in-bailiwick vanity names

	ns1.example.com
	ns2.example.com,

you can simply start out with the joint NS record set (the vanity names, and at least one of the out-of-bailiwick ones), then perform bootstrapping. When done, just drop the out-of-bailiwick ones from the NS rrset.

Rubens, I was not able to give this response ad hoc at the ROW discussion, but now I see more clearly. So, thank you for the discussion input -- it has clarified some things in my mind!

Best,
Peter

-- 
https://desec.io/