[DNSOP] Re: Is DELEXT too restrictive?

[Roy Arends <[e-mail]>]

> On 3 Aug 2026, at 16:49, Philip Homburg <[e-mail]> 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