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

[Mukund Sivaraman <[e-mail]>]

Hi Warren

On Mon, Nov 14, 2016 at 02:05:31PM +0900, Warren Kumari 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.

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.

> 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).

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

		Mukund