> On 29 Jul 2026, at 12:56, Philip Homburg <[email protected]> wrote:
>
>> The DE flag was introduced as a capability negotiation mechanism,
>> indicating that the resolver understands DELEG. Omitting the NS
>> RRset was a natural optimisation of the protocol semantics adopted
>> for DELEG (why send NS it if it is not used), but not the purpose
>> of the DE flag itself.
>
> For unsigned zones, there is no need for a capability negotiation. Just
> putting both NS and DELEG records in the Authority section is fine.
> If I remember correctly, somebody tested whether this would cause any
> problems. So originally, DE was just an optimization.
Philip, My recollection is slightly different.
The DE flag really was introduced as a capability negotiation mechanism. Later,
it turned out that sending both NS and DELEG in the referral didn’t actually
cause interoperability problems (I believe Shumon and I were the ones who
tested this).
Even after that, we kept the DE flag because it provided a useful signal for
measuring deployment and adoption.
My recollection is also that the current behaviour (sending either NS or
Delegation Types depending on the value of the DE flag) came later. In other
words, I don’t think DE was originally introduced as an optimisation; the
optimisation followed from the protocol semantics that eventually evolved
around it.
In any case, I don’t think the historical motivation is the important question.
The question today is whether DELEG/DELEXT should define the NS interaction for
all future Delegation Types, or whether that should be left to the individual
Delegation Type specifications.
> Later it was found that sending DELEG records to legacy resolvers could
> cause DNSSEC validation errors. So DE became required, but that does
> not change the original purpose of DE.
>
>>> do we want the extra
>>> complexity for this optimization or not. What does it mean operationally,
>>> when delegation replies get bigger due to inclusion of NS records.
>>
>> The Response size gets larger when all Delegation Types and NS
>> records are included, compared to solely Delegation Types. That is
>> indeed a consequence of my proposed modification. However, new
>> Delegation Types do not necessarily need to have a DELEG RRset, so
>> the cost of larger responses now should be offset against even
>> larger responses in the future, if we dont make the change.
>
> One option is to split the range of new parent types into delegation types
> and informational types. That makes it possible to keep the optimization
> while allowing new types that can be combined with NS.
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.
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.
On the other hand, if the resolver does implement a Delegation Type, it follows
that Delegation Type’s specification. If that specification requires that NS
not be used (as DELEG does), then the resolver MUST ignore the NS RRset.
This is similar in spirit to DNSSEC algorithm agility. A resolver is not
expected to understand future algorithms immediately; the protocol defines how
implementations behave until they do. I’m suggesting DELEXT should provide a
similar compatibility story for future Delegation Types, rather than requiring
every future “delegation” type to inherit DELEG’s semantics.
Roy
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
