Yes as Daisuke said, it’s a very unscientific approach to measure this. We use data from our load test rig plus some baseline network latency to arrive at estimates.
Our average also includes timeouts from some exotic domains and records that do not exist which probably originate from malware and all sorts of crap on our clients devices. It’s amazing the junk that people try to access. How did your test go with the tuning already suggested, did you see any improvements? From: Unbound-users <[email protected]> on behalf of Daisuke HIGASHI via Unbound-users <[email protected]> Date: Thursday, 27 November 2025 at 9:45 pm To: sir izake <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: How to measure cache hit resolution time in unbound 1.24.1 sir izake via Unbound-users <[email protected]<mailto:[email protected]>>: Just wanted to find out if there is a way to measure the cache hit resolution time in a dashboard? Unbound has no facility to measure cache hit resolution time. A method to measure cache hit time is to make query to names which always resolved with cache hit e.g. “dig -t NS . “; If the resolver is too busy and queries always remain stuck in its receive queue, its response (even for cache hit) would be delayed due to the queue dwell time, and queries may even be dropped.
