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

[Peter Thomassen <[e-mail]>]

[reposting as it looks like this did not get delivered during Mailman transition last week; original message sent on May 7]


Hi,

On 5/2/24 19:59, David Dong via RT wrote:
> Following up on this; does the group agree that "_dnssec" is OK?

Looking at what's been said in this thread:
- Two people have proposed to change the label, current proposal: _dnssec
- Two implementers have said they'd make the change but don't seem convinced
- The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced

The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ...


I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is.

The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like

- TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address,
- PTR at _catalog.example.com._signal ... for catalog zone membership,
- ...

If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label.

I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation.

Thanks,
Peter
+ Nils (for the "we"/author statements)


> Thank you.
> 
> Best regards,
> 
> David Dong
> IANA Services Sr. Specialist
> 
> On Mon Apr 22 11:42:15 2024, [e-mail] wrote:
>> On 20 Apr 2024, at 19:38, Paul Wouters wrote:
>>
>>> On Sat, 20 Apr 2024, Peter Thomassen wrote:
>>>
>>>> The authors certainly don't insist, but we'd need to pick a suitable
>>>> replacement for the "_signal" label.
>>>>
>>>> John proposed "_dnssec-signal" elsewhere in this thread.
>>>>
>>>> The authors would like to note that adding "_dnssec-" eats up 8 more
>>>> bytes, increasing chances that bootstrapping will fail due to the
>>>> _dsboot.<domain-name>._dnssec-signal.<nsname> length limitation.
>>>> Other than this (unnecessary?) use case narrowing, this choice seems
>>>> fine.
>>>>
>>>> That said, does this choice address your concerns?
>>>
>>> It would, but I would also be okay if it is just _dnssec.
>>>
>>
>> If the concern is that the label is too generic, “_dnssec” might be
>> too generic as well. If it is to be more precise, go with _ds-boot or
>> something more specific to the use case. I don’t have an
>> implementation in the mix, so it this isn’t a strong opinion.   If the
>> group agrees _dnssec is fine, then I am fine with it too.
>>
>> Scott
>>
>> =====================================
>> Scott Rose
>> NIST/CTL/WND
>> [e-mail]
>> ph: 301-975-8439
>> GoogleVoice: 571-249-3671
>> =====================================
> 

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525