[DNSOP] Re: draft-ietf-dnsop-delext and non-useful parent-si de types

For the record: After further discussion in person, I am now convinced that there is no need for a separate range to allow parent-side types with NS, reasons follow.

A resolver understanding such types is anticipated to also have DELEG support, in which case a DELEG delegation equivalent to the NS RRset may be used to establish the conditions for using another parent-side type from the currently proposed range, without NS.

When not synthesizing the required DELEG delegation on demand, it needs to be put statically into the zonefile, duplicating the information from the NS RRset. The downside remains that the DELEG and NS records can get out-of-sync. However, most zones migrating to DELEG will have to deal with that, so this problem isn't created here. Perhaps it then also doesn't need to get solved here.

Best,
Peter


On 7/23/26 16:04, Peter Thomassen wrote:
> Hi Ralf,
> 
> On 7/23/26 15:23, Ralf Weber wrote:
>>>> So, the question is: do we want delext to make it possible to define
>>>> new parent-side types that work with NS? or are we ok that all new
>>>> delegation types either need to be DELEG successors or be served
>>>> with DELEG?
>>>
>>> I'd strongly prefer the former: it will be almost no work to take this into account now, in comparison to when we don't but need it later.
>>
>> This was discussed early on in DELEG, and the consensus then was because every NS can be represented by a DELEG record that we did not need it. We then had a discussion if this should synthesised automatically and if this should be part of the spec and we said that this is implementation dependant and we should not describe it.
> 
> Yes, but the question was not about DELEG. There's no proposal to change the behavior you described.
> 
> The question was whether it should be made "possible to define new parent-side types that work with NS" (à la DS). DELEG may not need this, but perhaps something else.
> 
> It doesn't seem expensive to designate some part of the rrtype space for such use. For example, we could take the ranges currently anticipated in the draft OR'ed with the 0x200 bit (so we get 0xF200..0xF3EF public and 0xF3F0..0xF3FF private).
> 
> Best,
> Peter
> 

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

https://desec.io/

deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany

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

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]