I would be very interested in a bit more precision here. Is there a way to say what is permissible vs impermissible re TTLs, and is there a way to say what is desirable vs undesirable re TTLs? We all understand that longer TTLs reduce the frequency of refresh at the expense of slower response whenever the authoritative information changes. However, some fraction of the recursive resolvers impose minimum and/or maximum limits on the TTLs they receive from the authoritative servers.
Shortening TTLs increases the amount of traffic between the recursive resolvers and authoritative resolvers and lengthens the response time for some queries. However, I don’t think there is any service guarantee with respect to an individual query that is violated by shortening the TTL. Lengthening a TTL, on the other hand, does change one of the service guarantees. When there is a change in the entry in the authoritative server, what is the maximum time until that change is guaranteed to be propagated throughout the net? This depends primarily on the TTL. However, when the TTL is lengthened by the recursive resolvers, the upper bound for propagation of a change is similarly increased. Is there any common understanding of how much lengthening is permitted? Is commonplace? Let me make a guess that the only lengthening that takes place in practice is a floor of ten seconds. Comments? Thanks, Steve > On Dec 1, 2017, at 12:52 PM, Jared Mauch <ja...@puck.nether.net> wrote: > > > >> On Dec 1, 2017, at 12:23 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: >> >> On 1 Dec 2017, at 9:16, Ólafur Guðmundsson wrote: >> >>> We are getting into religion here, the original poster called people that >>> cap TTL's Heretics, >> >> Looking through the mail archives, no one other than you is using that term. > > I think this is subject to interpretation, some people view the done > differently. > The subject line felt hostile.. 2nd attempt to adjust subject-line to make it > less hostile. > > - jared > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
