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]
