On Dec 5, 2017, at 23:04, Lanlan Pan <abby...@gmail.com> wrote: > Some authorititatives set the NS RR TTL<60s, they don't follow the best > practice guide.
The trouble here is understanding the motivations of any particular parameter, and doing so at scale. You could assume as a resolver operator that a zone manager (note, not an authoritative server operator) has made a mistake when you get a response with a low TTL, or you could take the position that it's not your business to make such inferences. Local policy to meet your own objectives in the operation of your resolver is different from seeking to correct decisions made by zone managers. Assuming errors (hence "correction") is a slippery slope to having no single source of truth. There are protocol design decisions relating to TTLs that relate to metadata that a resolver operator *can't* reasonably adust, like signature validity periods. More philosophically, the loose-coherency and data persistence associated with caching works because its boundaries are understood. The ability to use the system as a whole relies upon an explicit contract between zone manager and resolver operator, and if that contract fractures, applications and user-experience will follow. Any changes to the contract (and I'm not suggesting there can't be changes) need to be conservative, well documented and carefully implemented. Playing fast and loose with the interpretation of TTLs on every other resolver doesn't sound like any of those things. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
