Dietpi Unbound configration need to fine tune

General Discussion
1

I just want to share information that in Unbound version : 1.25 there are new changes about cache. so dietpi unbound need to fine tune accordingly. as existing dietpi default configuration is neither fit in optimize settings

so i guess in dietpi either we have to go in any of these two options


server:
    prefetch: yes
    serve-expired: yes
    serve-expired-ttl: 86400         # one day, in seconds (default)
    serve-expired-client-timeout: 0  # for version 1.23.0 and latter


or


server:
    serve-expired: yes
    serve-expired-ttl: 86400            # one day, in seconds (default)
    serve-expired-client-timeout: 1800  # 1.8 seconds, in milliseconds (default since 1.23.0)

this time in dietpi prefetch: yes which contradict with serve-expired-client-timeout: 1800(default value in unbound), this must be 0 if unbound work as prior or if it is 1800 than prfetch must be no.

2

Why do you think prefetch: yes would contradict serve-expired: yes with (new) default serve-expired-client-timeout: 1800?

  • The new serve-expired: yes default behavior aims to not serve expired cache entries if the query can be resolved upstream within 1.8 seconds.
  • prefetch: yes aims to keep cache entries for frequent queries up-to-date, before they expire, to prevent the additional delay of up to 1.8 seconds. Prefetching is done asynchronously.

I do not interpret the two examples as the only reasonable combinations or contradicting, and prefetch as quite unrelated option which aims to prevent the need to send or query for expired cache entries, regardless whether the old or new default mode is used.

But maybe I missed something.

3

If we run both unbound version:1.22 & new 1.25 with existing dietpi unbound.conf than, newer version is slower as it add 1.8 sec on every dnsquery. also if you count the cache hits are much less as most of the queries come from fresh fetching from root servers(reply received within 1.8 second from root servers). In my home adguard home having multiple upstream one is unbound. in past unbound resolve about 60-70 % queries but after unbound new version upgrade its resolving was less than 10%. the normal cloudflare or opendns are faster than unbound everytime. only after making `serve-expired-client-timeout: 0 ` system go back to normal as old statics. may be it is my personal choice but i thought good to share with everybody here. some of people also complain regarding this in this forum for same problem. https://www.snbforums.com/threads/unbound-low-cache-hit-rate.95332/page-3

4

It does not add 1.8s to every DNS query: If there is an entry in the DNS cache, and that entry has expired (despite prefetch) for less than 1 day, it allows the (upstream) DNS query to take up to 1.8s, before it serves the expired entry from the cache. But usually, upstream queries are a lot faster. A quick test here took 0.030s for a fresh DNS query, and 0.001s for the same afterwards, as it has been stored in the cache. So upstream is usually still 1-2 magnitude of orders faster than this 1.8s fallback. And for new queries, or such where the cache entry expired for more than serve-expired-ttl: (1 day), Unbound does and always did allow the upstream query to take unlimited time.

Yes, the RFC-compliant serve-expired mode reduces the cache hit rate, but reduces the chance/risk that outdated DNS responses are sent. This is the tradeoff, and we chose to follow Unbound defaults for higher reliability, instead of restoring pre-1.23 defaults for a little cache hit rate gain that most users will still never recognize. prefetch is still enabled to reduce the chance that regularly called DNS queries expire in the first place.

If you want to max out the cache hit rate, you can set serve-expired-client-timeout: 0 of course, or even better, raise cache-min-ttl, which plays very well with prefetch as of the relatively small 10% window.

In my home adguard home having multiple upstream one is unbound.

What for do you use Unbound if you allow other upstreams aside of it? Also note that AdGuard Home as well as Pi-hole (dnsmasq) have their own DNS cache, so Unbound has no real purpose if it is not used for privacy to skip upstream providers, or use upstream DoT.

Sure, performance is not really a commonly intended goal of using Unbound. It is a recursive resolver, hence may do multiple queries from DNS root servers to final authoritative name servers, then does DNSSEC on top. Public DNS providers naturally can do that a lot faster, and keep every DNS query in cache with thousands/millions of requests to each of them each second. Of course with a local DNS cache, you can still be faster, but I’d usually rate reliability/accuracy of the response higher than whether it is some centiseconds faster, at least when it is about defaults for software that is commonly used for privacy purpose, not for maxing out DNS performance.

What we could do is exposing the serve-expired-client-timeout: commented out in our config, adding some lines that explain what it does, notably the effect of setting it to 0, to always serve cache entries expired since up to a day, instead querying upstream first.