On 18/03/2025 08.50, Shumon Huque wrote:
This cuts both ways though. Speaking from experience working with the customers of my employer, we've also seen numerous cases where the child NS rrset was correct and the parent was not - operator didn't realize they needed to update the delegation.
But the revalidation only solves it partially. I mean, a resolver (with a clear cache) first only sees the parent side, so if that one is (partially) broken, it's bad regardless of any child content that is in the various auths. Moreover, I suspect that in those broken states the different auths will have different NS record-sets anyway - like if you follow a glue leading to a provider that had been pushed out of the NSset but they forgot to remove them from the parent. So you will still revalidate with the wrong/unintended NS rrset.
If we let those teams think that touching only child side is enough, it will still break. In such a context, resolver-side workarounds seem like a bad approach to me. I'm even doubtful about them looking at EDE and fixing if it screams.
--Vladimir | knot-resolver.cz
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
