> On 3 Aug 2026, at 16:49, Philip Homburg <[email protected]> wrote:
>
>> I think were looking at this from slightly different angles.
>>
>> My example isnt intended to describe what I think operators will
>> do. Its intended to show what the protocol permits.
>>
>> Currently, DELEXT specifies that every future Delegation Type
>> inherits DELEGs interaction with NS (i.e. ignore NS) by default.
>> My concern is whether thats the right architectural choice for a
>> framework intended to support future Delegation Types.
>>
>> I also dont think the issue is specific to a hypothetical DELEG2.
>> It applies to any future Delegation Type that does not need DELEGs
>> NS replacing semantics. Under the current design, such a type either
>> has to require DELEG alongside it, or it has to change DELEXT.
>> Thats the design choice Im asking the working group to make
>> consciously now, rather than implicitly through DELEG.
>
> We can split the range in two
Philip, I appreciate that you acknowledge that there is an issue to be solved!
> - one part is for new delegation types. The assumption is that DELEG and
> any future delegation type will completely replace NS. So we can optimize
> delegation replies and leave out NS.
> - the other part is for non-delegation server-side types like DS. We can
> assume
> that they complement any delegation type including NS.
>
> If we assume new types DELEG2 and DS2. Then a delegation that has both
> NS and DELEG2 and the query has DE=1 then only DELEG2 would be returned.
> A delegation with both NS and DS2 (and a DE=1 query) would get both NS and
> DS2.
> A delegation with NS, DELEG2, and DS2 (and a DE=1 query) would get DELEG2
> and DS2.
Consider a resolver understands DS2, but not DELEG2. Since the authoritative
server omitted the NS RRset, the resolver has no delegation information it can
actually use.
To allow the internet to migrate from DELEG to DELEG2, operators would
therefore need to deploy both DELEG and DELEG2, each with its own signatures,
until DELEG2 is universally implemented. That seems like a fairly high
deployment cost to preserve a relatively small optimisation in referral size.
> I think that solves the problem. Though at the cost of a bit of extra
> complexity. Is there any objection to splitting the range?
I think my proposal keeps DELEXT itself simpler. Rather than having the generic
protocol decide, based on a type range, whether NS is replaced, each Delegation
Type defines its own interaction with NS. Existing implementations
automatically have a well-defined compatibility behaviour for future Delegation
Types that they do not yet implement.
That’s also why I drew the analogy with DNSSEC algorithm agility. The protocol
defines how implementations behave when they encounter something they don’t yet
understand, rather than requiring future extensions to inherit the semantics of
today’s ones.
Roy
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
