cache-max-ttl

Wouter Wijngaards wouter at nlnetlabs.nl
Mon Dec 3 14:52:36 UTC 2018


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> 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>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181203/b4c82423/attachment.bin>


More information about the Unbound-users mailing list