Note that the security benefits of NS revalidation only apply to "strictly revalidating" resolvers (Section 5.1). "Opportunistically revalidating" resolvers (Section 5.2) gain no meaningful security benefit. The draft does not seem to RECOMMEND "strict revalidation", presumably because it has slower resolution and higher SERVFAIL rate, and is not widely deployed.
Implicitly, at least, "opportunistic revalidation" seems to be the RECOMMENDED behavior. This recommendation must be justified by the benefits of opportunistic revalidation, which are operational, not security-oriented. --Ben Schwartz ________________________________ From: Willem Toorop <wil...@nlnetlabs.nl> Sent: Tuesday, March 18, 2025 11:23 AM To: Ondřej Surý <ond...@isc.org> Cc: Peter Thomassen <pe...@desec.io>; Ralf Weber <d...@fl1ger.de>; dnsop <dnsop@ietf.org>; dnsop-chairs <dnsop-cha...@ietf.org> Subject: [DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-ns-revalidation "Delegation Revalidation by DNS Resolvers" 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. >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
