On 3/18/25 10:21, Philip Homburg wrote:
I offered **two** alternatives to ns-revalidation draft:
A. I-D.fujiwara-dnsop-resolver-update
- attacks listed in ns-revalidation draft section 8.3 are not
applicable - zero additional cost in term of queries - easier to
operate/debug because parent-child NS mismatch suddenly does not
influence resolution algorithm - unilateral code-change in resolvers,
i.e. doable in the same time-frame as ns-revalidation
Maybe you can explain this a bit more?
I-D.fujiwara-dnsop-resolver-update has the following:
- Separate the cache into "authoritative data cache" and "delegation cache".
This suggests to me that a serious mismatch between parent and child will
also cause problems. May I missed something.
The child NS version will be ignored by recursive resolution algorithm
so any mismatch will not affect the result.
Can you describe the problem you have in mind?
- "Step 4.b." is changed as if the response contains a better delegation to
other servers, cache the delegation information into delegation cache,"
This seems to rely on auth. servers including delegation information in
answers to queries. When happens if replies are minimized?
I think there is some confusion. Here's
git diff --word-diff rfc1034 I-D.fujiwara-dnsop-resolver-update
on these two paragraphs between RFC 1034 section 5.3.3 and this I-D:
---------
b. if the response contains a better delegation to other servers, cache
the delegation [-information,-]{+information into delegation cache,+}
and go to step 2
---------
Are you suggesting that RFC 1034 section 5.3.3 does not work with
minimized answers? Probably not.
This behavior is implemented and deployed at scale by Akamai & Google
Public resolver, so I guess if there was a massive fallout we would have
heard by now.
But the big one seesm to be, this does not use DNSSEC protection for name
servers. The draft says:
"The update does not effect to DNSSEC [RFC4033] [RFC4034] [RFC4035] because
DNSSEC validates authoritative data and does not validate referrals."
The whole point is that the child-side NS RRset can be validated with DNSSEC
as well as any A/AAAA RRsets for the name servers.
I agree this is technical weak point.
Having said that, it does not affect integrity protection provided by
DNSSEC for authoritative data. In other words, an attacker is not able
to spoof authoritative answers from a signed domain. The best an
attacker can do is to spy by redirecting traffic, but well, if we are
after a real confidentiality DELEG is needed. Revalidation would provide
us with a complex band-aid, not a real solution.
I think we disagree in value judgement about this. I'm saying that
I-D.fujiwara-dnsop-resolver-update is so much simpler and with much
better behavior overall, compared to re-validation, so I'm willing to
accept this weak point.
In addition I-D.fujiwara-dnsop-resolver-update seems vulnerable to ghost-domain
attacks.
GHOST attack depends on child-side NS manipulation, and child-side is
not used at all for resolution by resolvers implementing this I-D. I
can't see how it could possibly be affected. On the contrary, this
change prevents GHOST from working!
Can you describe the mechanism you have in mind?
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
