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

[Peter Thomassen <[e-mail]>]

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 nohats.ca as an example)

	_dsboot.nohats.ca._signal.ns2.foobar.fi.

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 ns2.foobar.fi likes to signal something about nohats.ca. 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 https://datatracker.ietf.org/meeting/interim-2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa-authenticated-dnssec-bootstrapping-00.pdf
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/

Thanks,
Peter

-- 
https://desec.io/