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