> On 28 Jul 2026, at 20:53, John Levine <[email protected]> wrote:
>
> It appears that Michael Richardson <[email protected]> said:
>> (I don't really understand the pushback. I guess I shall re-read archives)
>
> It's the usual reason. It adds more complication to DNS servers for
> something that has no current use and as likely as not never will.
I’m not convinced it adds much complexity. In fact, on the authoritative server
side it arguably simplifies the logic: when DE=1, include the NS RRset and
Delegation Types. The server no longer needs to suppress NS based on the
presence of Delegation Types; the interaction between NS and a particular
Delegation Type is defined by that Delegation Type’s specification and enforced
by the resolver. The resolver already has to implement type-specific processing
for DELEG.
> How
> are you supposed to test it?
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.
> We're not that short of code points. If at some future time someone
> comes up with an actual use for DELEXT+NS, reserve some code points
> then.
The issue is not code point availability. The interaction between Delegation
Types and NS is currently defined by DELEXT itself, not by the individual
Delegation Type. Once DELEXT implementations are deployed with the rule that
the presence of any Delegation Type causes resolvers to ignore NS, a future
Delegation Type cannot opt out of that behaviour by obtaining a new RR type
code. At that point we’d have to change DELEXT itself, not just allocate a new
Delegation Type.
> PS: I don't expect to win this argument since adding cool new features is
> much more fun than thinking about how to test and maintain them all.
John, I don’t think this is a case of adding a speculative feature “just in
case”. Rather, it’s about avoiding hard-coding the semantics of one Delegation
Type into a framework that is explicitly intended to support many future
Delegation Types. If the WG decides that all future Delegation Types should
inherit DELEG’s NS suppressing semantics, that’s a perfectly valid
architectural decision. My point is that we should make that decision
consciously, because it will be difficult to change once DELEXT is deployed.
Roy
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
