Hi, On 3/18/2025 5:38 AM, 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. This is not possible if some of the major TLDs only offer very long unchangeable TTLs and resolvers don't interrogate the child NS RRset. You might argue that this problem could be solved by getting some of those TLDs to offer configurable TTLs, but guess what - we've been talking about that for ages with no significant movement, so other protocol solutions are needed.
I have some experience with NS revalidation implementation and operations. Since this feature prefers child NS RRset, some zones which are misconfigured fail to resolve after the revalidation (i.e. may return old/unexpected records from probably a decommissioned name server).
Resolver operators not knowing why such thing happened, while other public DNS providers resolving it correctly, ends up making support requests which then concludes with disabling the revalidation feature altogether. I guess this will happen with most deployments eventually disabling this option.
Regards, *Shreyas Zare* Technitium <https://technitium.com/>
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
