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 > <[email protected] <mailto:[email protected]> 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 > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> 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 > > <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> 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> >
