Bugzilla – Bug 4089
Unbound should hold open TLS connections
Last modified: 2019-03-17 12:41:44 CET
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:
Yes that is a good idea. For the forwarding case, realistically. Also for TCP.
Best regards, 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.
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.
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.
the relevant RFC in this context
has been updated with: