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

[Willem Toorop]

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?

-- Willem

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.

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.

OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org