On Mon, Nov 14, 2016 at 12:05 AM, Warren Kumari <[email protected]> wrote:
> Hi all, > > I have just submitted "Stretching DNS TTLs" > (draft-wkumari-dnsop-ttl-stretching-00). > > The very high level overview is: > If you are doing something like HAMMER / pre-fetch, and cannot reach > the authoritative server when trying to refresh a record, you may > continue to use a record past the TTL. > This is working on the theory that stale bread is better than no bread. > This is a strawman doc / idea, I'm expecting much discussion on if the > above is true. > > > NOTE: I believe that there may be (non-Google) IP associated with > this. A lawyer will be filing the IPR disclosure later today (time > zone differences, etc). > > W > > ---------- Forwarded message ---------- > From: <[email protected]> > Date: Mon, Nov 14, 2016 at 1:55 PM > Subject: New Version Notification for draft-wkumari-dnsop-ttl- > stretching-00.txt > To: Warren Kumari <[email protected]> > > > > A new version of I-D, draft-wkumari-dnsop-ttl-stretching-00.txt > has been successfully submitted by Warren Kumari and posted to the > IETF repository. > > Name: draft-wkumari-dnsop-ttl-stretching > Revision: 00 > Title: Stretching DNS TTLs > Document date: 2016-11-14 > Group: Individual Submission > Pages: 4 > URL: > https://www.ietf.org/internet-drafts/draft-wkumari-dnsop- > ttl-stretching-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-ttl-stretching/ > Htmlized: > https://tools.ietf.org/html/draft-wkumari-dnsop-ttl-stretching-00 > > > Abstract: > The TTL of a DNS Resource Record expresses how long a record may be > cached before it should be discarded. This document discusses the > possibility of "stretching TTLS" (using them past their expiration) > if they cannot be refreshed. This works on the assumption that stale > data may be better than no data. > > PLEASE NOTE: This document is a strawman to drive discussion. It may > or may not be a good idea; this document documents the idea so that > there is something concrete to throw tomatoes at. > I really like this idea. I would suggest that the resolver should go back up the tree (toward the root) until some level responds, to verify that the zone has not been removed, to avoid 'ghost zones'. So if looking up "host.subdomain.domain.tld" and the servers for "subdomain.domain.tld" are all non-responsive, then query the "domain.tld" servers to see if: 1. The delegation has not changed, in which case extend the ttl 2. The delegation has changed, then go query the new servers 3. The delegation has been removed, then drop the record from the cache. There could be more than one non-responsive level, so the resolver should repeat this at each level back toward the root until there is a response. If the root does not respond, then the resolver should extend the ttl. Separately, since TTL's can vary widely, I would suggest setting a minimum and maximum extension time. If a record has a very short ttl (like 1 second), I would like the option to tell the resolver to extend it by 10 or 30 seconds, to avoid a lot of retries. And if N is 10, do I want a 1 day ttl extended by a day, but a 1 sec ttl extends only to 10 seconds? Or perhaps there is a better algorithm. -- Bob Harold
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
