DoT with unbound
Havard Eidnes
he at uninett.no
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
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
More information about the Unbound-users
mailing list