[FR] Clear both in-memory and `cachedb` module cache with `unbound-control flush*` commands

[gjherbiet]

Current behavior

My understanding is that the cachedb module is used as a second-level cache: when a record is not in the in-memory cache, Unbound will try to fetch it from the cachedb module before resorting to the iterator module.

When clearing an entry from the cache (e.g. using unbound-control flush), the desired record is removed from the in-memory cache but kept in the cachedb chache. Then upon next request, it is fetched again from the cachedb and not processed by the iterator module. As a consequence, the cached value for the requested record is still served.

Describe the desired feature

When using the cachedb module, use of the unbound-control flush* commands shall delete requested entries from both the in-memory and cachedb caches.

An alternative would be to manually delete also the related entries in the cachedb storage (Redis-like in my case), but this would require :

• to know which entries have been removed from the in-memory cache (there might be several of those, potentially a large number with e.g. flush_zone)
• identify each storage key do delete, either by enumerating all the keys or by applying the same hashing that Unbound does.

Neither solution seems practically achievable.

Potential use-case

Clearing entries from the cache is a rather regular operation that operators of DNS resolvers have to perform when dealing with users that poorly managed their TTL during a DNS migration or that face an emergency situation.

System:

• Unbound version: 1.19.2 (backported to Debian 12 from Debian Salsa)
• OS: Debian 12 (bookworm)
• unbound -V output:

Version 1.19.2

Configure line: --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pythonmodule --with-pyunbound --enable-subnet --enable-dnstap --enable-systemd --enable-cachedb --with-libhiredis --with-libnghttp2 --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --disable-rpath --with-pidfile=/run/unbound.pid --with-libevent --enable-tfo-client --with-rootkey-file=/usr/share/dns/root.key --enable-tfo-server
Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.11 19 Sep 2023
Linked modules: dns64 python cachedb subnetcache respip validator iterator
TCP Fastopen feature available

BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues

Additional information

Below are relevant parts of the Unbound configuration:

server:
	module-config: "respip validator cachedb iterator"
	[...]
	serve-expired: yes
	serve-expired-ttl: 86400
	serve-expired-ttl-reset: no
	serve-expired-reply-ttl: 30
	serve-expired-client-timeout: 1800

cachedb:
	backend: "redis"
	secret-seed: "[REDACTED]"
	redis-server-host: 127.0.0.1
	redis-server-port: 6379
	redis-server-path: ""
	redis-server-password: "[REDACTED]"
	redis-timeout: 500
	redis-expire-records: yes

[kkkgo]

Indeed, this is a very practical requirement. Additionally, I am planning to seek an automated method to efficiently delete specific domain entries from the unbound cache or from the records in a Redis cache. In my DNS service application, I use unbound as an upstream server. I am concerned that if my DNS service application uses command-line calls to unbound-control, it might lead to significant process overhead, potentially resulting in reduced efficiency.

[wcawijngaards]

The commit adds the command flush +c www.example.com and the +c option makes it remove the message also out of the cachedb. Also for flush_type, flush_zone, flush_bogus and flush_negative. For the zone, bogus and negative commands, it flushes the names that are found in the local cache from the cachedb. That should stop it from immediately serving the same data from cachedb. Without the option the commands act as before, so that the server cache can be wiped without interfering with cachedb cache contents, if desired.