[DNSOP] Re: [Last-Call] Re: Re: [Ext] Last Call : <draft-ietf-dnsop-delext-07.txt> (DNS Protocol Modifi cations for Delegation Extensions) to Proposed Standard

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]