cachedb (Redis) cache marked as expired across Unbound instances, leads to repeated upstream queries

[kingsh2012]

How does Unbound's cachedb(or Redis caching module) work? How is it used and configured?

I have two Unbound instances (A and B) that are both connected to the same Redis (or Redis caching module). When instance A processes a request, the corresponding cache key is stored in Redis. However, when I make the same request from instance B, Unbound does not use the cached data from cachedb(Redis), but instead reports that the cache is marked as "expired", and then forwards the query to the upstream DNS. Is this normal behavior? The TTL (time-to-live) for my cache is set to about one day.

My Unbound service is mainly used for IoT devices. Currently, the QPS of requests received by Unbound is around 10,000/s, while the QPS forwarded to the upstream DNS is between 2,000 and 3,000/s. Since the upstream DNS has QPS limits, I want to find an effective way to reduce the query pressure on the upstream. To achieve this, I am using cachedb(or a Redis caching module) to minimize queries to the upstream and therefore reduce the upstream QPS.

Do you have any suggestions for a better architecture or solution to achieve this go

[kingsh2012]

This triggered the upstream QPS

[gthess]

The TTL (time-to-live) for my cache is set to about one day

Is that a Redis configuration you are referring to?

Unbound does store the DNS TTL of the message in the Redis backend and it uses that to check the DNS message expiry. If the answers you are getting from upstream have low TTLs, then the records, while still stored in Redis, they will be perceived as expired when their DNS TTL has expired.