cache-max-ttl

Eric Luehrsen ericluehrsen at gmail.com
Sat Dec 1 20:30:35 UTC 2018


this (new patch) appears to be the right behavior. you dont want each
client or intermedary to also set max TTL.

maybe your business internal DNS (file and print servers) is static for 7+
days, your DHCP server publishes 10 minutes for mobile devices, but you
want your gateway/DNS appliance to force 4-8 hour refresh of global
internet resources.

- Eric

On Sat, Dec 1, 2018, 11:59 AM Paul Wouters via Unbound-users <
unbound-users at nlnetlabs.nl wrote:

> Your suggestion seems to be what I would expect unbound to do.
>
> Paul
>
> Sent from mobile device
>
> > On Dec 1, 2018, at 11:12, Daisuke HIGASHI via Unbound-users <
> unbound-users at nlnetlabs.nl> wrote:
> >
> > Hi,
> >
> >   cache-max-ttl option defines upper-bound of RRsets TTL
> > but initial TTL value _shown_ by Unbound’s response is original TTL e.g.:
> >
> > original TTL: 86400
> > cache-max-ttl: 300
> >
> >  1. TTL value just after RRsets cached: 86400
> >  2. TTL value after 100 seconds: 86300
> >  3. TTL value after 299 seconds: 86101
> >  4. TTL value after 300 seconds: (expired)
> >
> >  This is documented behavior, but problematic if there is caching DNS
> proxy
> > (e.g. home router) between Unbound and client — The DNS proxy will cache
> > RRsets with large (86400) TTL and hold them long time regardless of
> > cache-max-ttl.
> >
> >  I think that Unbound's implementation should be changed so that
> > cache-max-ttl defines also upper-bound of initial TTL shown
> > by Unbound's response just like:
> >
> >  1. TTL value just after RRsets cached: 300
> >  2. TTL value after 100 seconds: 200
> >  3. TTL value after 299 seconds: 1
> >  4. TTL value after 300 seconds: (expired)
> >
> > A quick hack patch attached.
> > Is it useful? And is it harmless to existing Unbound deployments?
> >
> > Regards,
> > --
> > Daisuke HIGASHI
> > <min-ttl.patch>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181201/2cf737ab/attachment.htm>


More information about the Unbound-users mailing list