Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

Peter Thomassen <> Sat, 13 April 2024 01:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C6F1C14F721 for <>; Fri, 12 Apr 2024 18:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 6_8Q7fbJfI7Z for <>; Fri, 12 Apr 2024 18:23:52 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 37C86C14F703 for <>; Fri, 12 Apr 2024 18:23:51 -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: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=DDHqhu5d9dGszbc4/+hPNAj54G2G9H3fY5crPUNoMFg=; b=b6XUaHHu+yl2DATLecXtLXwto7 hls4J6xENf7fZ1b+2r6yILNKOHzdaKyRvNcqalG4JcNepb39TwtoHNR0eN823Ik5aXY1tlYwY3j5T kG+KDH9jakTB9IzyifyylHxnE7N/531NLEo8ZCVJE+nluujlQQr+g4WK8owVfbJ0vOzpZs1MIULF8 YoR9lUaeoOYQx3u8IYkUC3p2TpVtpB82nhl86mvEC4ils42Ly2G0bPxT8aSsvHJU5z3Yg2JtbYUH4 W9TFE9rT1fkz1t6fK8a1qArhF3fM3TAgRoCrgIRNSl942WbuPuuJCHODGCZfzgqGrk2nXlIAmBToI MrOq1PAA==;
Received: from [2a02:8109:9283:8800:c7bb:9d53:dc54:f646] by with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1rvS7N-00322W-5o; Sat, 13 Apr 2024 03:23:45 +0200
Message-ID: <>
Date: Sat, 13 Apr 2024 03:23:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Paul Wouters <>, David Dong via RT <>
Cc:, Nils Wisiol <>
References: <> <> <> <>
Content-Language: en-US
From: Peter Thomassen <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
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: Sat, 13 Apr 2024 01:23:57 -0000

Hi Paul,

On 4/12/24 22:36, Paul Wouters wrote:
> However, I would urge the authors/WG to pick a less generic and more
> specific name than "_signal", such as "_dnssec-bootstrap". Especially
> because there is also the well known "Signal" message client. Also,
> in case of future different signaling, the current name might become
> confusing.

The signaling record names actually have two underscore labels, and look like (taking as an example)

The specific type of signal is already indicated by the first label. Other signaling use cases would use a different first label. (draft-thomassen-dnsop-mske has an example.)

The _signal label generically indicates that likes to signal something about Its presence is needed to allow separating the object from the source without ambiguity.

We could change _signal to something else, but not to _dnssec-bootstrap as that's not generic. Suggestions are welcome.

I'd like to add some considerations:

- The spec has quite a few production implementations (see Section 8), and changing them would come with significant costs.

- I don't think the _signal label is in use for the Signal messenger. Even in case it's used in the future, a collision (in terms of prefix labels + rdtype) seems unlikely.

As there would be significant costs, but no tangible benefit, perhaps we should not do this.

Further context: The structure of the signaling name is the result of the DNSOP Interim [1]. Details on rejected alternatives can be found in [2].

[1]: "Open Issue 3" in