On 09. 07. 26 4:48, John R. Levine wrote:
On Wed, 8 Jul 2026, Dave Lawrence wrote:
Section 4 says
When the value of the EDNS(0) DE flag is 0, the server behaves as a
server that does not implement this specification, i.e., Delegation
Types are treated as Data Types.
Let's say I have this in my .EXAMPLE zone file:
foo.example. deleg server-ipv4=1.2.3.4
Then my dusty web server does an A request for foo.example. There's
no NS so there's no referral. But there's a DELEG record so it
returns NOERROR. That can't be right.
I don't really understand why you're saying that can't be right.
That a legacy client should just get service like it is talking to a
legacy server seems like a reasonably conservative position to take,
and 4.1 goes on to clarify what this means if there's no NS.
Hmmn, took a look at draft-ietf-deleg-10 5.2.2.1 which agrees that That
it returns NOERROR with the new INFO-CODE extended error, or NXDOMAIN
for names under the zone cut. I suppose that's no wronger than any of
the plausible alternatives.
It could do NXDOMAIN for the zone cut but I can see how that would be
confusing too.
NXDOMAIN would require maintaining two NSEC chains (for delext-aware and
delext-unaware clients) and that's big no-no from design standpoint.
Personally when I think about permissible behavior I do it 'backwards':
Start from a NSEC chain with delext-RRtype bit set in it, and then
derive how responses with it would be interpreted by legacy clients who
do not understand the new delext semantics.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
