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

[Willem Toorop]

Op 18-03-2025 om 08:27 schreef Ondřej Surý:

On 17. 3. 2025, at 23:16, Willem Toorop <wil...@nlnetlabs.nl> wrote:

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.

Willem,

this part caught my eye. Can we elaborate a little bit more?

0. With full 'on-path' attacker - there's no protection of unsigned zones with 
or without NS revalidation. Hope we can agree on this.

If physically on path, then yes we can agree on that.

But if the attackers is on-path because it hijacked all the name server IPs of a zone, then the attacker cannot also hijack referrals from that zone if it is not also able to hijack the authoritative NS RRset and addresses of that referred to zone. It can only block that delegation then.

So, what do you mean by partly on-path then?

For example if an attacker only hijacked part of the IP addresses of the name servers serving the zone.

There's 26 IP addresses for the RZ, there's 26 IP addresses for .com and .net.

1. If the attacker sits on the 1-26 IP addresses for the .com/.net, the 
unsigned zones are not protected, right? The attacker can give whatever the 
GLUE they want.

Correct. And also whatever the NS set they want pointing those names to an insecure zone for example to strengthen the attack. But a DNSSEC validating NS revalidating resolver will detect that and reject it.

2. If the attacker sits on 1-26 IP addresses for the RZ, this is where the NS 
revalidation will possibly help for validating resolver. It will not do any 
good for non-validating resolver, there's no difference as the attacker can 
just either directly hijack the name by returning the data, or return own 
referral.

There are some benefits for non-validating resolvers as well, but let's leave that out for the moment. (but see Haya's paper that I referenced before)

Now, correct me if I'm wrong – the whole NS revalidation process protects only 
DNSSEC-enabled resolvers against attacks on the unsigned domains against 
attackers on-path to the parent zone. Every other scenario is either directly 
vulnerable or can be worked around by the attacker.

There is a bit more to it (see again Haya's paper about how it protects non-parent centric resolvers against a whole series of other cache poisoning attacks), but that is the strongest measure against query redirection yes.

I get your point that this might improve the situation a little bit, but I 
don't share the conclusion that this is worth the effort and the additional 
complexity.

I understand that. It may be too complex to do in general, especially as the child side delegations become less reliable deeper in the tree, but doing it for example only at the root, as an extension to priming, would already make a big difference, especially since a root hijack equals a complete DNS tree hijack.

Thanks,

Welcome :)

-- Willem

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

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