On 3/18/25 13:37, Philip Homburg wrote:
Yes, I don't think it's even possible to completely solve on resolver
side. But the parent-only approach would be more predictable. Every
(conforming) resolver would see the same NS set, modulo TTL expiration.
Because it wouldn't depend on whether it has fetched a child NS *and*
from a "correct" child auth. (Say, if you forgot a wrong server in the
parent, I assume that server may very well serve you a wrong NS rrset.)
The problem I see is the following:
Suppose we have a parent-centric resolver that will never consider the child
NS RRset.
We assume that an attacker has somehow managed to subvert the priming query
for the root zone and take over queries that go to the root zone.
Now a parent-centric resolver will be at the mercy of the attacker. Obviously
the attacker cannot forge DNSSEC-signed data. But all unsigned zones can be
controlled by the attacker.
I think that's why proper term for these zones is 'insecure', not just
'unsigned'. The solution for this is 'secure them' = sign them.
Suppose we have another resolver that for DNSSEC-signed zones will query (and
validate) the child NS RRset and use that RRset instead. Then the attacker
would have to subvert queries to those nameservers as well. Just subverting
the root priming query would not be enough.
This is a question of attack model. If we say that this attack model is
unrealistic, then we should document that somewhere. And explcitly say
that those types of attacks will not be considered by the wg.
Actually a proper threat modelling for DNS might be an interesting and
useful exercise. We are getting lots of submissions from various
researchers, each of them making up their own threat model, which makes
pretty hard to evaluate proposed attacks.
As I see it, ns-revalidation seems to propose an improvement to one
corner case. In my opinion the added complexity is not worth the effort,
compared to benefits of implementing I-D.fujiwara-dnsop-resolver-update.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
