> On 15 Jul 2026, at 22:08, Donald Eastlake <[email protected]> wrote:
>
> Hi Roy,
>
> See below at <DE>
>
> On Tue, Jul 14, 2026 at 7:52 PM Roy Arends <[email protected]
> <mailto:[email protected]>> wrote:
>>
>> > On 14 Jul 2026, at 18:08, Donald Eastlake <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > Hi,
>> > ...
>> > This draft has an excellent and, as far as I can see, complete
>> > Security Considerations Section! The threat model is stated
>> > explicitly, the attacks are enumerated, and the residual-risk analysis
>> > is clear about the limits of protection. That is uncommon and
>> > commendable.
>>
>> Thank you Donald!
>>
>> > Issues
>> > ------
>> > These are really just questions:
>> > Is a statement needed to the effect that, to be secure, a resolver
>> > always needs to have obtained, validated, and be holding the DNSKEY
>> > RRset with ADT flag from X before following a referral from X?
>>
>> The current text implies it, but I agree it needs to be explicit.
>>
>> How about replacing 6.2 with the following text before the text in 6.2:
>>
>> Before following a referral from a DNSSEC-signed delegating zone, a
>> validating resolver MUST determine the authenticated state of the ADT
>> flag from a validated DNSKEY RRset for that zone.
>>
>> Followed by the current text in 6.2:
>>
>> When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the
>> DNSKEY RRset of the delegating zone, the validator MUST verify the
>> Delegation Type RRsets in the Authority section of the referral
>> against the Type Bit Maps of the NSEC or NSEC3 record that matches
>> the delegated name. If any are absent, the referral MUST be
>> considered tampered with, and the response MUST be ignored.
>
> <DE> Almost... What if it determines the ADT state from a validated DNSKEY
> RRset and the TTL expires or it gets crowded out of cache and then it needs
> to do another referral out of the zone. Perhaps you would say that means it
> no longer has that information so it has to refetch the DNSKEY RRset but I
> could imagine an implementation that remembers this about a zone.. This
> slightly fuzzy timing case is why I had said that it must be "holding" the
> DNSKEY RRset in my comment above.
Ah, I see the nuance now. How about:
On receiving a referral from a DNSSEC-signed delegating zone, a
validating resolver MUST determine the authenticated state of the ADT
flag from a validated DNSKEY RRset for that zone.
This way, the check is done on reception of the referral, before it is stored,
and before it is followed. Once it is stored, it can be re-used without having
to check the ADT flag.
>> > Should the draft point out that it makes unsigned zones a bit less
>> > secure from an injection attack? Currently injecting a referral
>> > competes with the legitimate answer but by requiring NS RRs to be
>> > ignored if there are Delegation Types, an injection can cause active
>> > discard of legitimate NS RRs.
>>
>> Section 8.3 (Injection of Delegation Types) concludes with the text:
>>
>> In unsigned zones, no cryptographic protection against this attack is
>> available.
>>
>> IMHO, it implies that it makes unsigned zones susceptible to injection
>> attacks.
>
> <DE> Yes, the draft is clear that unsigned zones are susceptible to injection
> attacks. My point was slightly more complex: If you inject NSs into a zone
> that has legitimate NSs then they compete on an equal footing with those
> legitimate NSs and you are slightly better off then if you inject Delegation
> Types into a zone that has legitimate NSs because the Delegation Types will
> completely eclipse the NSs that will then be ignored.
I do see your point. However, this scenario assumes an unsigned delegating zone
and an adversary capable of injecting referral responses. Such an adversary can
already forge or replace the referral, redirect the resolver to
adversary-controlled servers, or deny service. While the resolver’s behaviour
differs when processing NS records versus Delegation Types, I do not believe
this materially changes the adversary's capabilities or the security model.
Adding this distinction in resolver behaviour adds complexity without improving
the document. DNSSEC remains the intended defence against this class of attack.
Hope this helps, and thanks again for taking the time to review it and discuss
it!
Warmly,
Roy
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
