<div dir="auto"><div data-smartmail="gmail_signature">this (new patch) appears to be the right behavior. you dont want each client or intermedary to also set max TTL. </div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">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.</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">- Eric</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 1, 2018, 11:59 AM Paul Wouters via Unbound-users <<a href="mailto:unbound-users@nlnetlabs.nl">unbound-users@nlnetlabs.nl</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Your suggestion seems to be what I would expect unbound to do.<br>
<br>
Paul<br>
<br>
Sent from mobile device<br>
<br>
> On Dec 1, 2018, at 11:12, Daisuke HIGASHI via Unbound-users <<a href="mailto:unbound-users@nlnetlabs.nl" target="_blank" rel="noreferrer">unbound-users@nlnetlabs.nl</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
>   cache-max-ttl option defines upper-bound of RRsets TTL<br>
> but initial TTL value _shown_ by Unbound’s response is original TTL e.g.:<br>
> <br>
> original TTL: 86400<br>
> cache-max-ttl: 300<br>
> <br>
>  1. TTL value just after RRsets cached: 86400<br>
>  2. TTL value after 100 seconds: 86300<br>
>  3. TTL value after 299 seconds: 86101<br>
>  4. TTL value after 300 seconds: (expired)<br>
> <br>
>  This is documented behavior, but problematic if there is caching DNS proxy<br>
> (e.g. home router) between Unbound and client — The DNS proxy will cache<br>
> RRsets with large (86400) TTL and hold them long time regardless of<br>
> cache-max-ttl.<br>
> <br>
>  I think that Unbound's implementation should be changed so that<br>
> cache-max-ttl defines also upper-bound of initial TTL shown<br>
> by Unbound's response just like:<br>
> <br>
>  1. TTL value just after RRsets cached: 300<br>
>  2. TTL value after 100 seconds: 200<br>
>  3. TTL value after 299 seconds: 1<br>
>  4. TTL value after 300 seconds: (expired)<br>
> <br>
> A quick hack patch attached.<br>
> Is it useful? And is it harmless to existing Unbound deployments?<br>
> <br>
> Regards,<br>
> -- <br>
> Daisuke HIGASHI<br>
> <min-ttl.patch><br>
<br>
</blockquote></div>