Just a question regarding Redis memory size

[mattredact]

Curious as to why you decided on 4MB max for Redis.

I've noticed this usually maxes out cached entries in Redis around 6-7k. If I were to raise the limit to let's say 20-50MB, do you suggest any other tweaks in your Redis config that would work better with this memory limit?

Thanks again for the wonderful repo!

[ar51an]

That was done a long time ago for a small network. I am currently using maxmemory 8mb. Of course you can use maxmemory according to your requirement. I also mentioned in the readme Feel free to change them as preferred.

Few suggestions:

• Use maxmemory as a power of 2 (4, 8, 16 ...). It will be slightly more efficient.
• Do not use too big maxmemory, otherwise it will never fill up and existing entries will not recycle. maxmemory-policy will never kick in to evict least recently used keys. You will have too old stale data, which might throw error if it has been updated by the domain owner.

[mattredact]

Awesome.

Thanks a bunch for the advice. I will roll with 8mb for a bit and see how it works in my network.

Regarding the Unbound v1.20.0 issue with redis and the cachedb-check-when-serve-expired setting. I'm currently on v1.22.0. Is it still needed to set this to cachedb-check-when-serve-expired:no ?

If so, is commenting out serve-expired-reply-ttl: 0 necessary as well?

Cheers, and thanks again for this.

[ar51an]

cachedb-check-when-serve-expired: no
The functionality of cachedb-check-when-serve-expired remains the same since it was introduced in 1.20.0. It is better to use no. With yes it will serve expired records from cachedb even when the expired record exists in unbound's own cache. Cache Hits & Prefetch do not work as intended (you can observe it in dashboard after a day or so).

Here are some of my findings for cachedb behavior since unbound 1.20.0:
DNSSEC validation process for expired records from cachedb has been changed since unbound 1.20.0. In unbound 1.19.3 it used to serve the expired record from cachedb first and then performed the DNSSEC validation silently behind the scene. Since unbound 1.20.0 it performs DNSSEC validation before serving the expired record from cachedb. That is why Lookup Avg is higher even when the records are served from cachedb. You can validate it by disabling the DNSSEC validation in unbound, the response time (Lookup Avg) will be approximatley same as it was in unbound 1.19.3.

serve-expired-reply-ttl: 0
I have this commented out since unbound 1.20.0. Before unbound 1.20.0 there was a bug in serve-expired-reply-ttl behavior. It used to treat cache and cachedb records differently and threw a warning on unbound startup mentioning the same. Now expired records both from cache and cachedb are sent with serve-expired-reply-ttl: 30 which is the correct way.

[mattredact]

Thanks for this. I have tested with 1.17.1 and 1.22.0 and my avg recursion is

1.17.1 (without cachedb):

~70-80ms average recursion
~10-15ms median recursion

1.22.0 (with cachedb):

134.0ms average recursion (+~60ms)
63.7ms median recursion (+~50ms)

Exact same configuration, just only added Cachedb w/ Redis via Unix socket.

Is this due to v1.22.0? Would you advise reverting to a lower version Unbound? It is quite annoying to have much higher recursion times.

Cheers and thanks for the help!