DoT with unbound

Havard Eidnes he at
Mon Nov 25 13:42:57 UTC 2019

> 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

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

More information about the Unbound-users mailing list