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
