<div dir="auto"><div>Hi,</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Tue, Dec 11, 2018, 12:45 AM Petr Špaček 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">On 10. 12. 18 16:38, Gavin McCullagh via Unbound-users wrote:<br>
> Hi,<br>
> <br>
> I don't think this change is harmless. Both described behaviours are<br>
> useful, depending on the context. <br>
> <br>
> Downstream forwarding resolvers who forward through an upstream<br>
> recursive resolver do not always appreciate the paternalistic behaviour<br>
> of their upstream lowering ttls for them, which can cause lowered<br>
> performance and increased costs. And lots of support tickets.<br>
> <br>
> Where the upstream recursive resolver is unbound, the existing behaviour<br>
> is useful to just limit how long the upstream caches for without<br>
> impacting on how long the downstream can cache for. If the downstream<br>
> wants to set cache-max-ttl also, that is their prerogative, but it is<br>
> not forced on them by the upstream.<br>
<br>
I think this is incorrect oversimplification. The original behavior<br>
makes sense only if there is *exactly one* resolver forwarding to<br>
Unbound and nothing else.<br>
<br>
The original behavior gets pretty confusing in all other cases, e.g.:<br>
Multiple resolvers forwarding to the same Unbound instance. In this case<br>
an instance which asked first will see higher TTL than all other instances.<br>
<br>
>From my perspective it makes more sense to modify TTL in all cases as<br>
propsed in this patch, it is at least consistent.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I agree with you in many, but not all cases. There are use cases where the current behavior can be preferable.</div><div dir="auto"><br></div><div dir="auto">As a specific example, consider what a customer sees if they own both the authoritative zone and the sole client of their records. They set their TTL to 7200 and they set their caching resolver to forward through an unbound resolver with cache-max-ttl set to 120. <br></div><div dir="auto"><br></div><div dir="auto">When the customer makes the very first query for an rrset, they will see TTL=120 in the response. No matter how high they set their TTL, they always see a ttl between 0 and 120. In today's world they always see a response ttl between 7200 and 7080. What the customer sees is that their caching clients have an absolute max time between cache misses of 120 and an average well below that because the upstream resolver is "overriding" their chosen TTL and in particular, not allowing them to respect it downstream.</div><div dir="auto"><br></div><div dir="auto">The customer, who must wait for cache misses and pay the bill for queries on their hosted zone, does not appreciate this. So they complain that artificial TTL lowering is causing decreased performance for their forwarding resolver and clients. So the upstream must raise cache-max-ttl.</div><div dir="auto"><br></div><div dir="auto">Meanwhile another customer who makes a mistake on their authoritative records with a long TTL fixes their mistake and flushes their downstream caches but finds that the upstream resolver is caching the record, preventing recovery. The upstream resolver must now provide self service cache invalidation, but that's a bunch of extra work and complexity for both parties.</div><div dir="auto"><br></div><div dir="auto">My point is that there are use cases where one may want to be able to limit how long a recursive resolver caches records for, without overriding the TTLs seen by its clients and dictating how long they may cache for. </div><div dir="auto"><br></div><div dir="auto">Gavin</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Ideally, I would suggest offering both behaviours with different config<br>
> options.<br>
> <br>
> Gavin<br>
> <br>
> <br>
> <br>
> On Mon, Dec 3, 2018, 6:53 AM Wouter Wijngaards 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>
> 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<br>
> 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<br>
> 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>><br>
> <mailto:<a href="mailto:unbound-users@nlnetlabs.nl" target="_blank" rel="noreferrer">unbound-users@nlnetlabs.nl</a><br>
> <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><br>
> <mailto:<a href="mailto:unbound-users@nlnetlabs.nl" target="_blank" rel="noreferrer">unbound-users@nlnetlabs.nl</a>><br>
> <mailto:<a href="mailto:unbound-users@nlnetlabs.nl" target="_blank" rel="noreferrer">unbound-users@nlnetlabs.nl</a><br>
> <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<br>
> caching<br>
> > DNS proxy<br>
> > > (e.g. home router) between Unbound and client — The DNS<br>
> proxy will<br>
> > cache<br>
> > > RRsets with large (86400) TTL and hold them long time<br>
> 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<br>
> deployments?<br>
> > ><br>
> > > Regards,<br>
> > > --<br>
> > > Daisuke HIGASHI<br>
> > > <min-ttl.patch><br>
><br>
</blockquote></div></div></div>