[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-ns-revalidation "Delegation Revalidation by DNS Resolvers"

[Willem Toorop <[e-mail]>]

Op 17-03-2025 om 16:39 schreef Peter Thomassen:
> On 3/17/25 21:37, Willem Toorop wrote:
>>>> But many zones are still not DNSSEC signed. Making sure that 
>>>> responses are answered by the correct authoritative name servers 
>>>> (NS revalidation), protects the unsigned zones
>>> The thing is, there is no "making sure".
>> There is making sure if the authoritative NS RRset is signed
> :-)
>
> I was responding to your claim about unsigned zones. There is no 
> making sure via NS re-validation for them, precisely because the 
> authoritative NS RRset is not signed.
The claim stands! My claim is that protecting DNSSEC signed delegations 
(like almost all of the TLDs) by NS revalidation also protects all the 
DNSSEC unsigned zones that are delegated from those zones. I elaborate a 
bit further on that topic below.
> For secure zones, you surely can look-up the authoritative 
> (child-side) NS RRset and DNSSEC-validate it, exposing a fake 
> referral. However, you'd also detect that without NS revalidation (at 
> the cost of compromising privacy of the next query's question).
>> There is also a benefit with insecure delegations. Because the 
>> authoritative data is preferred, there is less opportunity to hijack 
>> once the authoritative data is in cache. As long as the authoritative 
>> data is not in cache, there is opportunity for an adversary to spoof 
>> this authoritative data.
> Eventually, the parent-side delegation will be refetched and override 
> the authoritative data, because the domain might have been redelegated.
>
> As an attacker who's in a position to serve fake stuff to a resolver, 
> wouldn't you thus spoof the referral, and the next time it gets 
> fetched, you win?
That is correct.
> I'm ready to be told that I'm just getting this wrong, but the above 
> points are the core to me. So let me rephrase this as a question:
>
> - For unsigned delegations, NS revalidation makes attack timing more 
> challenging (between caching the auth NS RRset and the delegation 
> re-fetch).
Indeed. It also does not counter /on-path/ or partly /on-path/ attacks.
> - For signed delegations, NS revalidation protects the privacy of the 
> actual query.

And in addition to that prevents all unsigned parts of the hijacked zone 
to be rewritten. For example if com is hijacked, unsigned zones like 
google.com can be redirected. Similarly if the root is hijacked all 
unsigned responses for the entire DNS can be rewritten.

NS revalidation of signed delegations is the only mitigation that 
protects against /on-path/ or partly /on-path/ attacks.

I love DNS cookies, and they are also a really good remedy for unsigned 
delegations, but they do nothing against on-path attacks.

> Does NS revalidation achieve anything beyond this?

Besides you underestimation of the impact of a hijack of a signed zone 
(especially higher up in the DNS tree), you have it covered :).

Also, responding to the reluctance of some to do revalidation in 
general, even doing it just at the root, which is the easiest and least 
risky, already has the biggest risk reduction.

-- Willem

>
> Best,
> Peter
>
> PS: This is not meant as a leading question; I'm trying to understand 
> what's really the benefit. It'll then be easier to weigh that against 
> complexity etc. The TTL logic in the draft, for example, isn't trivial.
>