Subject: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Nov 2016 14:05:31 +0900

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-masked]>
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-masked]>

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.

   [ Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.  This document is
   being collaborated on in Github at: https://github.com/wkumari/draft-
   wkumari-dnsop-ttl-stretching.  The most recent version of the
   document, open issues, etc should all be available here.  The authors
   (gratefully) accept pull requests ]

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Bob Harold <[email-masked]>
Date: Mon, 14 Nov 2016 12:31:51 -0500

>    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

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 27 Nov 2016 16:40:37 +0530

Hi Warren

> This is a strawman doc / idea, I'm expecting much discussion on if the

Apparently, there are a couple of approaches that implementations have
taken:

(1) In a proprietary patch for BIND:

- named as resolver first checks cache for a non-stale/unexpired answer

- If no answer is found, named performs resolution, and it has to send
  one or more fetches (query to an authoritative server)

- If the fetch takes more than a threshold time (but not as long as the
  timeout duration), named then serves any stale answer in the
  cache. But named keeps the fetch going until it times out. If the
  fetch eventually succeeds, the cache is updated.

- A stale cache entry is not used beyond a particular maximum time.

(2) In a feature implemented for Unbound:

- Unbound first checks cache

- If a stale answer is found, its TTL is set to 0, and the cache entry
  is served

- If a stale answer is found, Unbound starts something similar to
  prefetch/HAMMER.

> this. A lawyer will be filing the IPR disclosure later today (time

The two approaches are somewhat different, and so at least one of them
may not be covered by this patent.

		Mukund