John,
> On 3 Aug 2026, at 20:46, John Levine <[email protected]> wrote:
>
> It appears that Philip Homburg <[email protected]
> <mailto:[email protected]>> said:
>>> In the other direction, if you have a delegation point with only
>>> DELEG, and you sent a response to an old non-aware resolver with
>>> an authority section that has DELEG and maybe DS and maybe some
>>> RRSIGs, will resolvers ignore the useless (to them) stuff and treat
>>> it as NODATA, or barf because the authority section has garbage?
>>>
>>> I have no idea, perhaps people have tried it out.
>>>
>>> If the answer is NODATA the case for the DE bit is a lot weaker.
>>
>> There is a problem with DELEG validation. I don't remember all corner cases,
>> but DELEG-unaware validating resolvers may conclude bogus if they receive
>> DELEG records (which they believe is a child-side type) with a parent-side
>> signature.
>
> If someone knows concretely what the problem is, I'd be interested to hear
> about it.
> Resolvers check signatures on records they're going to ignore? That seems
> odd,
> although I suppose it's been a corner case that's not well tested.
I don’t recall seeing any evidence that validating resolvers declared such
responses bogus in the absence of the DE flag. The interoperability testing
Shumon and I have done was about whether legacy resolvers could cope with
referrals containing both NS and DELEG (legacy resolvers could indeed cope). If
anyone is aware of tests demonstrating DNSSEC validation failures without DE,
I’d be interested to see them.
As for DELEG records with a parent-side signature: In absence of an NS RRset
(and corresponding proof of absence), the legacy validating resolver is not
aware that it is looking at a delegation point. As a result, it does not apply
any special delegation semantics to the DELEG RRset. Instead, it treats DELEG
as an unknown authoritative RR type in the responding zone and validates its
RRSIG in the usual way for an unknown RR type.
I’m happy to be proven otherwise. However, it is independent of the discussion
about DELEXT being too restrictive.
Roy
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
