1.9.4: TCP queries when some threads are full

[Havard Eidnes]

In October, Wouter answered Patrik Lundin:

>> My second question is what the expected behaviour of unbound is for
>> TCP
>> connections that are idling. From unbound.conf(5) I see
>> "tcp-idle-timeout"
>> defaults to 30000ms, so this tells me a TCP connection being silent
>> for 30
>> seconds will be dropped but maby this only matters until we have seen
>> an
>> initial query and will then leave the connection forever?
>> I tracked down the file descriptor for one of the TCP connections to
>> unbound, found it was created over 12 hours ago, and then filtered for
>> traffic for the host and port that was holding the connection with
>> tcpdump, and not a single packet appeared for the several minutes I
>> was running
>> it.
>
> When TCP is nearly full it should use an even shorter timeout.  And
> not allow such very long idle connections.  That looks like it went
> wrong.

Hm, that didn't really answer the questions, though, did it,
other than perhaps implying that there's a bug?

Is there a different timeout used between the connection is
established and the first query is received than after the first
query is received?  I'm going to assume the intention is "no".

The experience I had with a mis-configured unbound for
dns-over-tls (all 10 slots used up pretty quickly, and connection
requests piling up, taking ages to respond if at all), and also
the other message at

  https://nlnetlabs.nl/pipermail/unbound-users/2019-August/011748.html

seems to indicate that the tcp-idle-timeout feature doesn't
actually work the way one would think it is supposed to work.
This makes me wonder if this feature has actually been tested and
verified to work as intended?

Regards,

- Håvard