Bug 4089

Summary: Unbound should hold open TLS connections
Product: unbound Reporter: Pascal <Pascal>
Component: serverAssignee: unbound team <unbound-team>
Status: ASSIGNED ---    
Severity: enhancement CC: cathya, djcater, ericluehrsen, jtodd, mail, n-nlnetlabs, wouter, wsokolowski
Priority: P5    
Version: 1.7.0   
Hardware: Other   
OS: Linux   

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.
https://tools.ietf.org/html/rfc7858

My config file includes:
ssl-upstream: yes
forward-zone:
 name: "."
 forward-addr: 1.1.1.1@853
 forward-addr: 1.0.0.1@853
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.
Thanks
Eric
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
Hello.
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 
https://tools.ietf.org/html/rfc7766
has been updated with:
https://tools.ietf.org/html/rfc8490