On Tue, Mar 18, 2025 at 11:29 AM Peter Thomassen <pe...@desec.io> wrote:
> Hi Shumon, > > On 3/18/25 07:08, Shumon Huque wrote: > > One more mundane operational benefit I haven't seen mentioned in this > discussion -- since ns-revalidation prefers the authoritative child NS > RRset, that puts control of rapidity of NS RRset changes firmly into the > hands of the child zone operator. We've had huge problems in the past with > some of our DNS vendors routinely messing up (over the course of multiple > years sometimes), where we would have to frequently eject one or the other > vendor out of the NS RRset and have those changes visible quickly. > > Just for my educational benefit, how does that work? > > Even a child-centric resolver will eventually look at the delegation again > (to catch re-delegation), and may then again end up at the NS that you had > intended to remove. Removing an NS RR from the child-side RRset thus does > not prevent queries from arriving at that NS. > 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. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
