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/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
