On 3/17/25 21:37, Willem Toorop wrote:
But many zones are still not DNSSEC signed. Making sure that responses are
answered by the correct authoritative name servers (NS revalidation), protects
the unsigned zones
The thing is, there is no "making sure".
There is making sure if the authoritative NS RRset is signed
:-)
I was responding to your claim about unsigned zones. There is no making sure
via NS re-validation for them, precisely because the authoritative NS RRset is
not signed.
For secure zones, you surely can look-up the authoritative (child-side) NS
RRset and DNSSEC-validate it, exposing a fake referral. However, you'd also
detect that without NS revalidation (at the cost of compromising privacy of the
next query's question).
There is also a benefit with insecure delegations. Because the authoritative
data is preferred, there is less opportunity to hijack once the authoritative
data is in cache. As long as the authoritative data is not in cache, there is
opportunity for an adversary to spoof this authoritative data.
Eventually, the parent-side delegation will be refetched and override the
authoritative data, because the domain might have been redelegated.
As an attacker who's in a position to serve fake stuff to a resolver, wouldn't
you thus spoof the referral, and the next time it gets fetched, you win?
I'm ready to be told that I'm just getting this wrong, but the above points are
the core to me. So let me rephrase this as a question:
- For unsigned delegations, NS revalidation makes attack timing more
challenging (between caching the auth NS RRset and the delegation re-fetch).
- For signed delegations, NS revalidation protects the privacy of the actual
query.
Does NS revalidation achieve anything beyond this?
Best,
Peter
PS: This is not meant as a leading question; I'm trying to understand what's
really the benefit. It'll then be easier to weigh that against complexity etc.
The TTL logic in the draft, for example, isn't trivial.
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
