Moin! On 19 Mar 2025, at 5:42, Shumon Huque wrote: > I spoke to Ralf Weber in-person a bit about this draft -- and Ralf, who is > clearly not a fan of this draft, is nevertheless fine with letting the > publication of ns-revalidation proceed in its current form and designation > (Standards Track and normative SHOULDs).
That is correct. Now that does not mean that we can not change the draft and after thinking about it a lot over the last couple of days let me give you my thoughts and maybe we can come to a common understanding. When this draft was started I was the only one questioning the benefits so I was and am still grateful that section 8.3 was put in reflecting this. Now over the last couple of years it seems that more people saw that and now agree with me and I am also happy about that. Now to be fair implementing re validation offers two benefits - For well behaved authorities it allows faster switching of name servers - For well behaved authorities it helps against certain scenarios of an partial on path attacker However it does not help against a full on path attacker, as the only things helping there are DNSSEC for detection and encrypting the connection for privacy. Re validation does not help with any of the cache positing attacks discovered over the last two decades, in fact one could argue that it increases the attack surface here because of issuing additional queries that can be attacked. Draft fujiwara-dnsop-resolver-update, which is roughly how Akamais resolvers and MaraDNS behave, offers protection against almost all of them. So it really comes down to choosing were you see the most benefits and/or the least risk and there are reasons for both and I think both Shumon and I understand why we are coming to different conclusions, and to be honest I think having different implementations is a good thing for the overall DNS ecosystem. Now I don’t think we should resurrect Draft fujiwara-dnsop-resolver-update, as I think we should spend our time elsewhere (deleg), but I certainly will not oppose it if someone does that, but I think maybe if we agree on the above put that discussion maybe somewhere earlier in the draft and then work on deleg which has this properly defined from the start and will also solve the privacy problem with finally encrypting connections between resolvers and authorities. So long -Ralf ——- Ralf Weber _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
