Re: [DNSOP] Measuring DNS TTL Violations in the wild

Mukund Sivaraman <muks@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 <dwessels@verisign.com>
> > wrote:
> >
> > >
> > > > On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson <
> olafur@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