On Tue, Mar 18, 2025 at 12:22 PM Peter Thomassen <pe...@desec.io> wrote:
> > > On 3/18/25 11:54, Shumon Huque wrote: > > > Follow-up: I guess only updating the NS RRset in the child zone > can still cause some queries to go to the faulty operator - you are right > about that. So, you have to do it both at the delegation and child zone. > Which is what we do. > > > > Excellent, that's what I'd thought. I'm just not getting which > difference NS revalidation then makes in this situation (as you brought it > up as an operational benefit upthread). > [...] > > > > Re-checking the delegation happens at the smaller TTL of the delegating > NS RRset and the Child zone apex NS RRset. So, the child zone can dictate a > smaller TTL in accordance with their operational needs for faster > reconfiguration, Does that answer your question? > > Absolutely, yes! > > So this is about when the parent is quick to deploy the update but has a > long TTL. Resolvers who query for the first time (or re-check the > delegation) will see the update from the parent anyway; however, resolvers > who have the NS RRset cached (and are not intending to query the parent) > would not have seen the update so quickly if they'd adhere to the > parent-side TTL. > That's correct. > I had been under the impression that the issue was parents who are slow to > update the delegation. Thanks for this! > I'm not aware that this is a problem. It is certainly not for the set of parents that we routinely work with. They are generally quick to update. The issue has always been how to get those updates visible rapidly. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
