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
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
