On Sat, Feb 23, 2019 at 1:54 PM <internet-dra...@ietf.org> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : Serving Stale Data to Improve DNS Resiliency > Authors : David C Lawrence > Warren "Ace" Kumari > Puneet Sood > Filename : draft-ietf-dnsop-serve-stale-03.txt > Pages : 11 > Date : 2019-02-23 > > Abstract: > This draft defines a method for recursive resolvers to use stale DNS > data to avoid outages when authoritative nameservers cannot be > reached to refresh expired data. It updates the definition of TTL > from [RFC1034], [RFC1035], and [RFC2181] to make it clear that data > can be kept in the cache beyond the TTL expiry and used for responses > when a refreshed answer is not readily available. One of the > motivations for serve-stale is to make the DNS more resilient to DoS > attacks, and thereby make them less attractive as an attack vector. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-serve-stale-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-03 > > In section 5: Will the "resolution recheck timer" cause ttl's less than the timer to be effectively lengthened, by refusing to look them up again?
I think 'serve-stale' should focus on the situation where the auth server is not available, and not change the handling of short ttl's. Or am I mis-reading that? -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
