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>
