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

[Willem Toorop <[e-mail]>]

Op 18-03-2025 om 08:20 schreef Peter Thomassen:
> 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.
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
>