Question about cache optimizer + serve expired (unbound)

Help Community Help
1

The issue I am facing:
I use unbound and I set the config to use serve expired entries, max ttl of 1 day and prefetch. I think I saw this advice somewhere to increase the number of queries served from cache. However, I noticed that pihole v6 has a cache optimizer which seems like it kind of serves the purpose of increasing the number of responses from cache, just at a different layer in the process.

My question is, should I revert to the standard config for unbound that is in the docs now that v6 is out?

Thank you in advance!

    # https://github.com/anudeepND/pihole-unbound
    cache-min-ttl: 300
    cache-max-ttl: 86400

    # Other recommended config for serve-expired with zero min ttl
    # cache-min-ttl: 0
    serve-expired: yes

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    #root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    ## Fetch DNSKEYs earlier in the validation process when a DS record is encountered.
    # https://github.com/anudeepND/pihole-unbound
    prefetch-key: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    ## More cache memory. rrset-cache-size should be twice what the msg-cache-size is.
    # https://github.com/anudeepND/pihole-unbound
    msg-cache-size: 50m
    rrset-cache-size: 100m

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

Details about my system:
Raspberry pi 5, bare metal install with unbound as recursive upstream server

What I have changed since installing Pi-hole:
Unbound config, longer TTL and serve expired enabled. Prefetching enabled.

2

On a side note, I'd be reluctant to interfere with TTLs as configured by domain owners, i.e. I wouldn't recommend to overwrite DNS information by using cache-max-ttl and particularly cache-min-ttl if you aren't aware of the consequences. That said, your value of 5 minutes seems justifiable, not likely to trigger unwanted behaviour very often.

Pi-hole's cache optimiser and unbound's serve-expired, in the way you've configured it, very much do the same thing, so you could consider to disable serve-expired, or switch it to a slightly different behaviour, where it would only serve stale cached records if retrieving a fresh reply would take too long, e.g.:

server:
    (…)
    serve-expired: yes
    serve-expired-ttl: 86400            # do not serve replies older than one day, in seconds
    serve-expired-client-timeout: 1000  # serve expired replies when resolution takes longer than 1.0 seconds, in milliseconds

If a client requests resolution of an already expired cached record, Pi-hole would immediately serve stale data from its cache to clients while refreshing its cache by sending a DNS request to unbound, and unbound would start resolution and only serve stale data from its own cache if it wouldn't be able to complete resolution in one second.
This would increase likelihood that Pi-hole receives fresh, valid DNS records instead of just replacing its own stale record with a stale reply from unbound's cache.

unbound's prefetch option would trigger it to retrieve fresh replies if a record is served from cache requested within the last 10% of its TTL, i.e. before it is expired.
This feature won't have a chance to kick in if clients would cache unbound's reply themselves, as such a client would only send a DNS request once its TTL has expired, making it largely useless in a scenario where a local DNS server like Pi-hole aggregates traffic of an entire network.

Note that even with if clients would send DNS requests directly to unbound, prefetching would only kick in if one of the client would request a cached DNS record within the last 10% of its TTL.
It would depend on client behaviour if you'd actually benefit from this, and how much that would be able to improve Pi-hole and unbound already serving stale cached data.

You could either consider to disable unbound's prefetching, or to disable Pi-hole's cache altogether.
If you do the latter, you should be aware that Pi-hole won't be able to perform DNSSEC validation anymore, and all replies would be marginally slower, as Pi-hole would always have to forward allowed requests to unbound instead of serving them straight from its cache.