On 3/18/25 12:39, Willem Toorop wrote:
- 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.
First, .com is signed, so I'm not sure how you'd hijack it as a whole.
With an NS revalidating resolvers this is impossible, because the authoritative
[child] side .com NS RRset is signed.
Sure, the hijacker can't fake .com's apex NS RRset and have it validate, so NS
revalidation would catch a spoofed referral from the root to .com.
But, even with NS revalidation, the hijacker *can* fake unsigned delegations
within .com. This seems to be effectively the same as injecting a proxy into
the .com referral from the root, where the proxy forwards secure responses
unmodified and only fakes unsigned delegations within .com.
An attacker who is in a position to do the former likely can also do the
latter. Applying NS revalidation thus seems to make no difference with regards
to insecure delegation hijacking, even in signed zones.
Best,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
