Bug 4089 - Unbound should hold open TLS connections
Unbound should hold open TLS connections
Product: unbound
Classification: Unclassified
Component: server
Other Linux
: P5 enhancement
Assigned To: unbound team
Depends on:
  Show dependency treegraph
Reported: 2018-04-16 04:45 CEST by Pascal
Modified: 2019-03-17 12:41 CET (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Pascal 2018-04-16 04:45:49 CEST
Currently unbound closes the connection immediately after it receives a response.

From RFC7858 (Specification for DNS over TLS):
   In order to amortize TCP and TLS connection setup costs, clients and
   servers SHOULD NOT immediately close a connection after each
   response.  Instead, clients and servers SHOULD reuse existing
   connections for subsequent queries as long as they have sufficient
   resources.  In some cases, this means that clients and servers may
   need to keep idle connections open for some amount of time.

My config file includes:
ssl-upstream: yes
 name: "."
Comment 1 Wouter Wijngaards 2018-04-18 07:19:21 CEST
Hi Pascal,

Yes that is a good idea.  For the forwarding case, realistically.  Also for TCP.

Best regards, Wouter
Comment 2 Eric Luehrsen 2018-09-25 05:58:13 CEST
Hi Wouter,
Holding TLS connections open rather than always starting a new one could help with:  https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4149 or at least potentially improve diagnosing it. I know it would probably only delay the problem, and not fix it. Anything might be worth a try though.
Comment 3 John Todd 2018-12-17 07:38:06 CET
This has a significant performance and bandwidth impact on recursive resolvers that implement DNS-over-TLS, as clients with large unbound forwarding arrays in front of significant client bases potentially can create DoS-like conditions for those upstream recursive resolvers. Current advice is: "Move to knot or bind or even stubby, which have pipelining" but nobody likes to suggest re-architecting to replace a component that works well in other areas.
Comment 4 Wojciech Sokołowski 2018-12-20 10:34:50 CET
I was using unbound with  DNS over TLS with some bigger volume of requests. In my case lack of reusing connection affected on high delay. I can even say unacceptable delays of >15s.
Comment 5 nusenu 2019-03-17 12:41:44 CET
the relevant RFC in this context 
has been updated with: