Mukund Sivaraman <m...@isc.org>于2017年12月2日周六 下午10:39写道：
> On Fri, Dec 01, 2017 at 05:16:47PM +0000, Ólafur Guðmundsson wrote: > > On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane <dwess...@verisign.com> > > wrote: > > > > > > > > > On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson < > ola...@cloudflare.com> > > > wrote: > > > > > > > > I strongly disagree with your "terminology", TTL is a hint about > maximum > > > caching period, not a demand or a contract. > > > > > > You say its just a hint. If you put a TTL of 1 hour on your data, and > I > > > have a recursive name server that reuses it for 2 hours, 12 hours, 5 > > > days... thats okay? > > > > > > If its just a hint then we are we spending all this effort on "serve > > > stale"? > > > > > > DW > > > > > > > > Strictly speaking yes, it is the same as when a Secondary does not update > > the zone for a long time. > > An authoritiative server operator knows what the consequence of setting > SOA RDATA fields is. It isn't the same as a cache extending TTL as it > sees fit, in spite of the loose coherency among primary and secondaries. > > I don't agree a downstream cache has authoritiative say about extending > TTLs (except exceptional circumstances where the authority is > unreachable ~serve-stale). > Some authorititatives set the NS RR TTL<60s, they don't follow the best practice guide. Authoritatives think they "do the right thing" to spread latest NS RR. Needless to say A RR. Some resolvers extend all RR's TTL<60s to 3600s，just to reduce the queries, when the authority is reachable. Resolvers think they "do the right thing", too. > Mukund > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
