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. I'm confused about why this is a solution for you. Do you just accept that those queries will go wrong? (which may be fine, of course, it just doesn't sound like "control of rapidity of NS RRset changes firmly into the hands of the child zone operator") Cheers, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
