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

[Warren Kumari <[e-mail]>]

On Sun, Nov 27, 2016 at 6:10 AM Mukund Sivaraman <[e-mail]> wrote:

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

Dear all,

I'd like to apologize for not having responded (onlist) until now - this
was not me ignoring you, rather we were getting our ducks in a row...

David Lawrence and I have been chatting since Seoul - he is the author of
the above patch; I'm planning on abandoning
draft-wkumari-dnsop-ttl-stretching and he and I will (soon) be releasing a
joint document which describes the behavior in his patch. This will be
describing running code, and so will / should be closer to ready for
publication.


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

Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole was
acquired by Akamai in March 2015. I believe that David will discuss the IPR
with his employer.

 W

>
>                 Mukund
>