Hi

We are using unbound docker containers (version 1.22) in our corporate environment and after fixing an issue with DNSSEC records, I wanted to ask about some of the logging statistics to see if there still might be an performance issue.

Last week, we were getting reports of certain domains not resolving and I saw error messages like the following in the logs:

    [1747490624] unbound[1:2] info: validation failure <wpad.domain.com. A IN>: SERVFAIL [exceeded the maximum number of sends] no DS for DS domain.com. while building chain of trust     [1747493945] unbound[1:1] error: SERVFAIL <wpad.domain.com. A IN>: exceeded the maximum number of sends

I ended up adding the following which seemed to resolve the issue:

        max-sent-count: 200

I had tried some lower values initially, but that didn't resolve the problem until I bumped it up to 200.


So at the moment we are not getting any reports for DNS client failues, but I am seeing the following in the logs:

   [1747757273] unbound[1:0] info: server stats for thread 0:
   requestlist max 78 avg 68.4251 exceeded 84 jostled 0
   [1747757333] unbound[1:0] info: server stats for thread 0:
   requestlist max 72 avg 66.9528 exceeded 55 jostled 0
   [1747757393] unbound[1:0] info: server stats for thread 0:
   requestlist max 78 avg 66.9892 exceeded 62 jostled 0


The thread server stats is always showing a significant number for exceeded. The host where the container is running is not overloaded. I do see in the logs that there are a significant number of requests for legacy subdomains that are no longer in use and cause error messages like the following:

   [1747758108] unbound[1:0] error: SERVFAIL <db01-dev.dev.domain.com.
   A IN>: all the configured stub or forward servers failed, at zone
   domain.com. from 10.10.32.2 got SERVFAIL

My main question is, would those requests that are being forwarded and timing out with a client error "no servers could be reached" be a source for the "exceeded" count in the thread server stats?

Thanks,

-Mike Durkin





Reply via email to