Bug 1168 - reuse TCP connections when possible
reuse TCP connections when possible
Product: unbound
Classification: Unclassified
Component: server
i386 OpenBSD
: P5 enhancement
Assigned To: unbound team
Depends on:
  Show dependency treegraph
Reported: 2016-11-30 16:02 CET by Boudewijn Dijkstra
Modified: 2019-01-22 11:45 CET (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Boudewijn Dijkstra 2016-11-30 16:02:20 CET
I'm using the unbound daemon on a LAN, with a forward-zone with 2 nearby addresses and forward-first enabled.

In order to prevent spoofing attacks, I thought it would be a good idea to enable tcp-upstream. However, today I discovered that the daemon seems to open a new TCP connection for every query, even with num-threads: 1 and outgoing-range: 1.

I have an application that sometimes performs about ~100 lookups at once (asynchronously). This works mostly fine with UDP, but with TCP I get bad performance, if most answers are not cached. The upstream servers don't seem to like the high number of SYNs, which is understandable.

When tcp-upstream is enabled, I think it would be very sensible to have the following policy with respect to outgoing TCP connections:
* keep existing ones open
* reuse when available
* have nominally one per upstream address, per thread.

To ensure that client and server agree on the message boundary, I guess the connection should be closed and re-opened on incomplete/corrupt answers and on unexpected ID numbers.
Comment 1 Wouter Wijngaards 2016-12-01 09:26:01 CET
Hi Boudewijn,

A patch for this is worked on.  And may already be available (for try out), from sinodun.

If you control the upstream servers, and it is unbound.  Increase num-tcp, compile with libevent, and then thousands of tcp connections should not be a problem.  That could also solve your issue.

Best regards, Wouter
Comment 2 Boudewijn Dijkstra 2016-12-07 16:26:32 CET
Hi Wouter,

Upstream servers are controlled by my ISP.  They might already support thousands of TCP connections without problems, but still reject a high SYN rate per source IP.

Anyway, how can I find out whether such a patch is available and if so, where to get it?   Does Sinodun know about this issue?

Comment 3 Wouter Wijngaards 2016-12-09 14:11:30 CET
Hi Boudewijn,

I told Sara (from Sinodun) about it, and the patch for this may not be ready yet for try out, but I think it might be close.  If so, maybe you are interested in trying it out, when it hits 'beta'?

Best regards, Wouter
Comment 4 Boudewijn Dijkstra 2016-12-13 11:16:27 CET
Hi Wouter,

Yes, I am interested in trying it out.
Comment 5 Wouter Wijngaards 2016-12-13 11:21:06 CET
Hi Boudewijn,

Sara emailed in an said she did not have anything useful to share, although work could maybe resume depending on funding and time in the future.

So, thank you for the offer to help test, but it turns out the other side (beta code) is not available right now.

Best regards, Wouter
Comment 6 Boudewijn Dijkstra 2018-06-18 12:41:27 CEST
An update: it turns out that one of my ISP's DNS servers was having trouble accepting TCP connections. So the client-side performance issue has been resolved, though implementing this enhancement is still likely to reduce server load in some cases.