Bugzilla – Full Text Bug Listing
|Summary:||Unbound should hold open TLS connections|
|Component:||server||Assignee:||unbound team <unbound-team>|
|Severity:||enhancement||CC:||cathya, djcater, ericluehrsen, jtodd, mail, n-nlnetlabs, wouter, wsokolowski|
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: 188.8.131.52@853 forward-addr: 184.108.40.206@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.