[DNSOP] Re: Is DELEXT too restrictive?

[Petr Špaček <[e-mail]>]

On 29. 07. 26 0:11, John R Levine wrote:
> On Tue, 28 Jul 2026, Roy Arends wrote:
>> I don’t see testing as a significant obstacle. The behaviour is 
>> deterministic and the interoperability matrix is finite. It doesn’t 
>> seem fundamentally different from the behaviours we’re already 
>> specifying and testing.
> 
> Hmmn, now that I look at it again I see I misread part of it.  Oops.
> 
> If it treats all the deleg-range types the same and always sends the NS, 
> sure, why not.  It still doesn't seem likely to be useful but it's 
> harmless.
> 
> Bonus question: does it also send glue?  I'd assume so or some of the NS 
> aren't going to be very useful.
As you pointed out, if we are going this route and always send NS RRset 
we have to send glue, too, otherwise the NS might be useless.

In principle this works.

With an implementer hat on: I don't like it.

This always-add-NS behavior prevents my auth implementation from reaping 
any performance benefits from DELEG. NS special processing causes extra 
lookups into database and potentially addition of multiple RRsets (NS 
owner names) for the associated glue records. This is way more work than 
putting one self-contained DELEG RRset into the response. As a case in 
point, NS special processing is an origin of CVE-2024-11187, so it is 
not a made-up problem. Extra work on top of all this comes from 
compression of multiple RRsets, too.


Another angle is that adding useless records might blow up the response 
over EDNS buffer size limit, and then we need very very clear rules when 
to set TC=1. That means redoing RFC 9471 and considering (NS + glue + 
all Delegation Types) at once.


Having said all this, the performance benefit might not outweigh 
benefits of this design, assuming we are able to get TC=1 rules correctly.

A potential optimization is an EDNS option with bitmap of supported 
NS+Delegation Types. With that an auth can (optionally) limit RRs in 
response only to types supported by the requestor. In future that might 
mean that DELEG flag set in the bitmap might mean 'skip NS'. But even 
with this bitmap we still need to define rules for TC=1, which are 
currently lacking.

-- 
Petr Špaček