> On 29 Jul 2026, at 15:57, Philip Homburg <[email protected]> wrote: > >> Assume that, in the future, a new Delegation Type supersedes >> DELEG. Existing resolvers understand DELEG and NS, but not the >> new type. >> >> With the current DELEXT semantics (or with a split where >> "delegation types" suppress NS), the referral would contain the >> new Delegation Type but no NS RRset. Since the resolver doesn't >> implement the new Delegation Type, it cannot use it, and because >> there is no NS RRset, it cannot fall back to the legacy delegation >> either. The delegation therefore becomes unusable for those >> resolvers. > > This assumes that operators will add delegations for the new delegation > type, leave out DELEG but keep NS when they know that many resolvers > don't support the new type. That seems rather odd behavior of operators.
I think we’re looking at this from slightly different angles. My example isn’t intended to describe what I think operators will do. It’s intended to show what the protocol permits. Currently, DELEXT specifies that every future Delegation Type inherits DELEG’s interaction with NS (i.e. ignore NS) by default. My concern is whether that’s the right architectural choice for a framework intended to support future Delegation Types. I also don’t think the issue is specific to a hypothetical “DELEG2”. It applies to any future Delegation Type that does not need DELEG’s NS replacing semantics. Under the current design, such a type either has to require DELEG alongside it, or it has to change DELEXT. That’s the design choice I’m asking the working group to make consciously now, rather than implicitly through DELEG. > >> My suggestion is slightly different. If a resolver does not >> implement any of the Delegation Types in the referral, but the >> referral validates correctly, it falls back to the NS RRset. >> Therefore the NS RRset needs to be included in the referral. > > To me it seems weird to always include the NS RRset in a DELEG delegation > (potentially leading to a truncated reply) only because in the future we > may introduce a new delegation type and don't want to require operators > to have a DELEG delegation. > > In the future we could also allocate a new EDNS(0) option to allow more > precise > signalling of what the client supports. We certainly could, but that reinforces my concern rather than removing it. If accommodating a future Delegation Type requires a new EDNS negotiation mechanism, that suggests DELEXT may not have been generic enough. My proposal is to avoid baking one particular Delegation Type’s NS semantics into the generic protocol in the first place. > > Note that a new delegation type without corresponding DELEG RRset is quite > similar to what is already discussed, a DELEG RRset without NS RRset. We > can defined that to result in NODATA/NXDOMAIN. The same would happen with > a new delegation type and no fallback to either NS or DELEG. I think that’s exactly the point. Today, DELEXT defines the interaction between all Delegation Types and NS according to DELEG’s requirements. My proposal is to move that decision back into the individual Delegation Type specifications, while leaving DELEG’s behaviour unchanged. Roy _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
