cache-max-ttl

[Gavin McCullagh]

Hi,

I don't think this change is harmless.  Both described behaviours are
useful, depending on the context.

Downstream forwarding resolvers who forward through an upstream recursive
resolver do not always appreciate the paternalistic behaviour of their
upstream lowering ttls for them, which can cause lowered performance and
increased costs.  And lots of support tickets.

Where the upstream recursive resolver is unbound, the existing behaviour is
useful to just limit how long the upstream caches for without impacting on
how long the downstream can cache for.  If the downstream wants to set
cache-max-ttl also, that is their prerogative, but it is not forced on them
by the upstream.

Ideally, I would suggest offering both behaviours with different config
options.

Gavin



On Mon, Dec 3, 2018, 6:53 AM Wouter Wijngaards via Unbound-users <
unbound-users at nlnetlabs.nl wrote:

> Hi,
>
> Ok, I have fixed it like this patch says.
>
> The suggested patch contains an if-statement too many.
> Fixed patch:
>
> Index: util/data/msgreply.c
> ===================================================================
> --- util/data/msgreply.c        (revision 5006)
> +++ util/data/msgreply.c        (working copy)
> @@ -195,6 +195,8 @@
>         }
>         if(*rr_ttl < MIN_TTL)
>                 *rr_ttl = MIN_TTL;
> +       if(*rr_ttl > MAX_TTL)
> +               *rr_ttl = MAX_TTL;
>         if(*rr_ttl < data->ttl)
>                 data->ttl = *rr_ttl;
>
>
> Best regards, Wouter
>
> On 12/1/18 9:30 PM, Eric Luehrsen via Unbound-users wrote:
> > 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 <mailto: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 <mailto: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/20181210/f89d979b/attachment.htm>