Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

Brian Dickson <> Wed, 22 June 2022 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A191C15AD35 for <>; Tue, 21 Jun 2022 23:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LaqVh0kZjgDk for <>; Tue, 21 Jun 2022 23:37:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 15692C157B37 for <>; Tue, 21 Jun 2022 23:37:01 -0700 (PDT)
Received: by with SMTP id k7so14549534plg.7 for <>; Tue, 21 Jun 2022 23:37:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tHAUjVGyyIXmp/bXZrX15+blJxC1ZDtczqnpfo59/dk=; b=OACxh8CalKY7gzkwIkNkKfEzF71vpii1M17OTTJBnQfd4QtM3+PO/HiwYjILO2wTGn DOkRsuzVGCMFtV9C2Rp41xdxRyfCQTdLb2X0iRxxlscB1RHNAcy8YLeiS0HsDgXXy7r1 vZ/AESNXBczDOAOgcrwRTgi1wjtmq17Re5otTW6+fcYAkF8DbARX2V6C+bvEUIenMDul UuW2KKrD+rLfiQkzZs6uWTI5d6dmoRIcpiVnO2FRxjgceEet+lMtVyFHnwcuv8SeTgSx d0b7pibxqTZAj8b7g/uiQ0YKO8Tz3p+YYTfuisNOVrOxlrbud8io6P5+7UOTPugnUC4n ok9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tHAUjVGyyIXmp/bXZrX15+blJxC1ZDtczqnpfo59/dk=; b=b7uAD98H6ZoECyn8b1EQtvlkNl3huSSXiQ0XjAsFUG8/Q9+b3FK40mwzr1FN1Wwgz3 H6/28Qt9r/3TDp9xUF84HyrBczILq0dt8SsL62u9yJ/4/bqu2YTYIk1EG1SYpGAmdH2l PtFFhyIjasfqmwenohEYvKtRkWkCL522jLNr/6/BGB5MXlY4B+bl4DBMH2Ocea+b0C9N d+EXTQ1rjG50Iud/R0fy7dBpOpzZ2lfcHK6kRE/rcQqcIIWJkT67vdiazfl0jTQonVe4 4LcD0g/yIu+KWUz0WBMjQEf1NQOfjznyDiCwZY4g6wRhVSAwL8x/TWpOWWudNmebo9wa 1XYg==
X-Gm-Message-State: AJIora/I53Sqp3IPY5ZhnpqcYAFdjace1Y2e9p8ZWMdjlsxPyuDN7BhR DmeErCnwLNRcbc4Bxuqeb15SW2v8zDo1qThnhxczQigK
X-Google-Smtp-Source: AGRyM1vPxJqFBXALIo89tQMQ2YDlvmC4mqau9xr3gF8oq/A++YggAlZfO/XaHCfHlkNhHQeEN5yu8abJ+JG0RvJB8a8=
X-Received: by 2002:a17:903:300d:b0:16a:b0c:333 with SMTP id o13-20020a170903300d00b0016a0b0c0333mr24107541pla.26.1655879820228; Tue, 21 Jun 2022 23:37:00 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Tue, 21 Jun 2022 23:36:49 -0700
Message-ID: <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="00000000000079bbba05e20390d6"
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 06:37:05 -0000

On Tue, Jun 21, 2022 at 7:51 PM <> wrote:

> 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.
Even if that is true, why bother?

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.

Even if procuring the services from a DNS operator costs a small amount for
the time it takes to do the bootstrap and migration, knowing that it works
and is secure, and does not require any work on implementing something that
is never going to be reused, would seem to be a small price to pay.

You may even have friends operating their own signed zones, via which you
can bootstrap this way for free.