cache-max-ttl

[Petr Špaček]

On 10. 12. 18 16:38, Gavin McCullagh via Unbound-users wrote:
> 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.

I think this is incorrect oversimplification. The original behavior
makes sense only if there is *exactly one* resolver forwarding to
Unbound and nothing else.

The original behavior gets pretty confusing in all other cases, e.g.:
Multiple resolvers forwarding to the same Unbound instance. In this case
an instance which asked first will see higher TTL than all other instances.

>From my perspective it makes more sense to modify TTL in all cases as
propsed in this patch, it is at least consistent.

Petr Špaček  @  CZ.NIC

> 
> 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 <mailto: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>
>     <mailto: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>
>     <mailto: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>
>