> What might be causing this? I beleive I now have the answer to this: the default settings for num-threads and num-incoming-tcp in unbound are wildly inappropriate for a TCP-heavy workload, such as providing a DNS-over-TLS service.
num-threads does not have a documented default value (bug!), but by the looks of it, it appears that the default is 1, i.e. unthreaded operation. num-incoming-tcp has a documented value of "10 per thread". Trying to exceed 10 simultaneous DNS-over-TLS connections is quite easy in my case. The documentation says "buffers", but I suspect it should really say "file descriptors"; a buffer doesn't by necessity map 1:1 to a file descriptor. Furthermore, I'm casting a little doubt over the tcp-idle-timeout handling and the back-pressre to free up connections it's supposed to provide; if it was active when 10 connecions were active (with the defaults in the config), the idle-timeout should have gone down to 60ms on 35% free and 0ms on "all slots taken", and that just didn't match what I observed. I've not delved deeper into why this didn't appear to kick in. I've for now bumped # of threads to 10 and number of "buffers" per thread to 100 (while still using the mini-event select() loop), and unbound seems to behave much better now. Best regards, - Håvard
