Op 18-03-2025 om 08:20 schreef Peter Thomassen:
On 3/18/25 12:39, Willem Toorop wrote: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.With an NS revalidating resolvers this is impossible, because the authoritative [child] side .com NS RRset is signed.- 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.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.
Indeed the same effect. But a different method.
An attacker who is in a position to do the former likely can also do the latter.
Not necessarily. Some IPs are easier to hijack than others.
Applying NS revalidation thus seems to make no difference with regards to insecure delegation hijacking, even in signed zones.
It guarantees the referral responses are coming from the intended name servers IPs and thereby more likely to come from the intended name servers.
So yes, it protects against hijacked IPs on the internet, but not to an on path attacker inbetween the resolver and its connection to the internet.
-- Willem
Best, Peter
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
