Prefetch Serve expired behavior per cache

Unbound
1

Hello All,

I am a newbie for unbound, please apologize if my question is wrong or my understanding is wrong.

I see below variables make unbound to use a single configuration for all cache resolvers.
As these variables are global and don’t bind with any unbound context or configuration for each cache

I wonder how to solve this problem? as I need different cache conf for different cache resolvers.

[64 ](https://indexing2.f5net.com/source/xref/tmos-dns-bugs/ports/unbound/build/util/data/msgreply.c#64) /** If we serve expired entries and prefetch them */
[65 ](https://indexing2.f5net.com/source/xref/tmos-dns-bugs/ports/unbound/build/util/data/msgreply.c#65) [THREAD](https://indexing2.f5net.com/source/s?defs=THREAD&project=tmos-dns-bugs) **int** [SERVE_EXPIRED](https://indexing2.f5net.com/source/s?refs=SERVE_EXPIRED&project=tmos-dns-bugs) = 0;
[66 ](https://indexing2.f5net.com/source/xref/tmos-dns-bugs/ports/unbound/build/util/data/msgreply.c#66) /** Time to serve records after expiration */
[67 ](https://indexing2.f5net.com/source/xref/tmos-dns-bugs/ports/unbound/build/util/data/msgreply.c#67) [THREAD](https://indexing2.f5net.com/source/s?defs=THREAD&project=tmos-dns-bugs) [time_t](https://indexing2.f5net.com/source/s?defs=time_t&project=tmos-dns-bugs) [SERVE_EXPIRED_TTL](https://indexing2.f5net.com/source/s?refs=SERVE_EXPIRED_TTL&project=tmos-dns-bugs) = 0;
[68 ](https://indexing2.f5net.com/source/xref/tmos-dns-bugs/ports/unbound/build/util/data/msgreply.c#68) /** TTL to use for expired records */
[69 ](https://indexing2.f5net.com/source/xref/tmos-dns-bugs/ports/unbound/build/util/data/msgreply.c#69) [THREAD](https://indexing2.f5net.com/source/s?defs=THREAD&project=tmos-dns-bugs) [time_t](https://indexing2.f5net.com/source/s?defs=time_t&project=tmos-dns-bugs) [SERVE_EXPIRED_REPLY_TTL](https://indexing2.f5net.com/source/s?refs=SERVE_EXPIRED_REPLY_TTL&project=tmos-dns-bugs) = 30;



Thanks,

Ashok
2

Hi Ashok,

The Unbound daemon runs as one cache resolver.
Are you perhaps using libunound and creating your own contexts?
In that case yes the options are per context.
You can have different options per context though, if you use the 'ub_ctx_set_option' function.
Since the options you mention are configurable and not hard coded, the aforementioned function works on them.

Best regards,
-- George

3 
Hello George,


Thanks for the quick response, Yes I am using libunbound version 1.12

Yes I am setting config for a separate context

but SERVE_EXPIRED_REPLY_TTL  is a global variable and the same is used in different places example dns.c tomsg() function
I feel because of this global variable this part of the code is creating problems for different cache conf.
I tested with multiple caches and its holding only 1 configuration (I doubt it because of code services/cache/dns.c#594)


SERVE_EXPIRED_REPLY is assigned in build/util/config_file.c#2056 (config_apply)2056  	

SERVE_EXPIRED_REPLY_TTL = (time_t)config->serve_expired_reply_ttl;


below code tomsg() is depending on SERVE_EXPIRED_REPLY_TTL to make this works these variables should be set in the context before actually calling tomsg() function. 

Else these values may remain un changed and apply for all caches.

As you can see in the below code services/cache/dns.c#594
589  	msg = gen_dns_msg(region, q, r->rrset_count);

590  	if(!msg) return NULL;

591  	msg->rep->flags = r->flags;

592  	msg->rep->qdcount = r->qdcount;

593  	msg->rep->ttl = is_expired

594  		?SERVE_EXPIRED_REPLY_TTL

595  		:r->ttl - now;

596  	if(r->prefetch_ttl > now)

597  		msg->rep->prefetch_ttl = r->prefetch_ttl - now;

598  	else

599  		msg->rep->prefetch_ttl = PREFETCH_TTL_CALC(msg->rep->ttl);

600  	msg->rep->serve_expired_ttl = msg->rep->ttl + SERVE_EXPIRED_TTL;


Thanks,

Ashok
4

Hello Everyone,

Can anyone guide me here ?

Thanks,
Ashok

5

Hi Ashok,

These variables are indeed global. They are meant to facilitate deep function calls that don't have a reference to the configuration.
I see how they can be a problem when you are using the library with multiple contexts.
May I suggest you create the different contexts in different processes (e.g., fork)?

If you don't care about using the different contexts in parallel, a context that finalizes its configuration (e.g., by resolving for the first time) will overwrite these values. Forking is not required then.

Hope that helps.

Best regards,
-- George