On Tue, Mar 18, 2025 at 11:37 AM Shumon Huque <shu...@gmail.com> wrote:
> 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. > 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. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
