<div dir="auto">Hi,<div dir="auto"><br></div><div dir="auto">I don't think this change is harmless.  Both described behaviours are useful, depending on the context.  </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Ideally, I would suggest offering both behaviours with different config options.</div><div dir="auto"><br></div><div dir="auto">Gavin</div><div dir="auto"><br></div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Mon, Dec 3, 2018, 6:53 AM Wouter Wijngaards 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">Hi,<br>
<br>
Ok, I have fixed it like this patch says.<br>
<br>
The suggested patch contains an if-statement too many.<br>
Fixed patch:<br>
<br>
Index: util/data/msgreply.c<br>
===================================================================<br>
--- util/data/msgreply.c        (revision 5006)<br>
+++ util/data/msgreply.c        (working copy)<br>
@@ -195,6 +195,8 @@<br>
        }<br>
        if(*rr_ttl < MIN_TTL)<br>
                *rr_ttl = MIN_TTL;<br>
+       if(*rr_ttl > MAX_TTL)<br>
+               *rr_ttl = MAX_TTL;<br>
        if(*rr_ttl < data->ttl)<br>
                data->ttl = *rr_ttl;<br>
<br>
<br>
Best regards, Wouter<br>
<br>
On 12/1/18 9:30 PM, Eric Luehrsen via Unbound-users wrote:<br>
> this (new patch) appears to be the right behavior. you dont want each<br>
> client or intermedary to also set max TTL. <br>
> <br>
> maybe your business internal DNS (file and print servers) is static for<br>
> 7+ days, your DHCP server publishes 10 minutes for mobile devices, but<br>
> you want your gateway/DNS appliance to force 4-8 hour refresh of global<br>
> internet resources.<br>
> <br>
> - Eric<br>
> <br>
> On Sat, Dec 1, 2018, 11:59 AM Paul Wouters via Unbound-users<br>
> <<a href="mailto:unbound-users@nlnetlabs.nl" target="_blank" rel="noreferrer">unbound-users@nlnetlabs.nl</a> <mailto:<a href="mailto:unbound-users@nlnetlabs.nl" target="_blank" rel="noreferrer">unbound-users@nlnetlabs.nl</a>> wrote:<br>
> <br>
>     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<br>
>     <<a href="mailto:unbound-users@nlnetlabs.nl" target="_blank" rel="noreferrer">unbound-users@nlnetlabs.nl</a> <mailto:<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<br>
>     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<br>
>     DNS proxy<br>
>     > (e.g. home router) between Unbound and client — The DNS proxy will<br>
>     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>
<br><br>
</blockquote></div></div>