On Tue, Mar 18, 2025 at 11:49 AM Peter Thomassen <pe...@desec.io> wrote:
> > > On 3/18/25 11:41, Shumon Huque wrote: > > We remove the faulty DNS operator from the NS RRset both at the > delegator and the child zone. > > > > But even if you just removed it from the child zone NS RRset, > ns-revalidation requires the resolver to re-query the NS RRset at the child > zone apex immediately after (re-)following the referral from the parent, > and replace the higher credibility (authoritative) data in cache. > > > > > > 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). > > Cheers, > Peter > 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? Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
