cache-max-ttl
Gavin McCullagh
gmccullagh at gmail.com
Tue Dec 11 11:42:41 UTC 2018
Hi,
On Tue, Dec 11, 2018, 12:45 AM Petr Špaček via Unbound-users <
unbound-users at nlnetlabs.nl wrote:
> On 10. 12. 18 16:38, Gavin McCullagh via Unbound-users wrote:
> > Hi,
> >
> > I don't think this change is harmless. Both described behaviours are
> > useful, depending on the context.
> >
> > 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.
> >
> > 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.
>
> I think this is incorrect oversimplification. The original behavior
> makes sense only if there is *exactly one* resolver forwarding to
> Unbound and nothing else.
>
> The original behavior gets pretty confusing in all other cases, e.g.:
> Multiple resolvers forwarding to the same Unbound instance. In this case
> an instance which asked first will see higher TTL than all other instances.
>
> From my perspective it makes more sense to modify TTL in all cases as
> propsed in this patch, it is at least consistent.
>
I agree with you in many, but not all cases. There are use cases where the
current behavior can be preferable.
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.
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.
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.
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.
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.
Gavin
> > Ideally, I would suggest offering both behaviours with different config
> > options.
> >
> > Gavin
> >
> >
> >
> > On Mon, Dec 3, 2018, 6:53 AM Wouter Wijngaards via Unbound-users
> > <unbound-users at nlnetlabs.nl <mailto:unbound-users at nlnetlabs.nl> wrote:
> >
> > Hi,
> >
> > Ok, I have fixed it like this patch says.
> >
> > The suggested patch contains an if-statement too many.
> > Fixed patch:
> >
> > Index: util/data/msgreply.c
> > ===================================================================
> > --- util/data/msgreply.c (revision 5006)
> > +++ util/data/msgreply.c (working copy)
> > @@ -195,6 +195,8 @@
> > }
> > if(*rr_ttl < MIN_TTL)
> > *rr_ttl = MIN_TTL;
> > + if(*rr_ttl > MAX_TTL)
> > + *rr_ttl = MAX_TTL;
> > if(*rr_ttl < data->ttl)
> > data->ttl = *rr_ttl;
> >
> >
> > Best regards, Wouter
> >
> > On 12/1/18 9:30 PM, Eric Luehrsen via Unbound-users wrote:
> > > 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
> > > <unbound-users at nlnetlabs.nl <mailto:unbound-users at nlnetlabs.nl>
> > <mailto:unbound-users at nlnetlabs.nl
> > <mailto:unbound-users at nlnetlabs.nl>> 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
> > > <unbound-users at nlnetlabs.nl
> > <mailto:unbound-users at nlnetlabs.nl>
> > <mailto:unbound-users at nlnetlabs.nl
> > <mailto:unbound-users at nlnetlabs.nl>>> 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>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181211/3b83686c/attachment.htm>
More information about the Unbound-users
mailing list