On Tue, Mar 18, 2025 at 2:37 PM Shreyas Zare <shreyas= 40technitium....@dmarc.ietf.org> wrote:
> 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. > This cuts both ways though. Speaking from experience working with the customers of my employer, we've also seen numerous cases where the child NS rrset was correct and the parent was not - operator didn't realize they needed to update the delegation. So, one other benefit I see to ns-revalidation is that it allows the resolver to collect telemetry about mismatch between NS RRsets on both sides of the zone cut and report that - the draft mentions the use of EDE and Error Reporting channels for this purpose. Ultimately, that may help the DNS ecosystem (if it were widely deployed of course) go back to enforcing the ancient dictum from RFC 1034 that the administrators for both sides of the zone cut need to insure that NS sets are consistent. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
