Reduce number of TLS connections to forwarded (DoT) when using "forward-tls-upstream" #47
Comments
|
Hi Fabio, |
|
Hi Ralph. |
|
Hi @ralphdolmans @wcawijngaards |
|
Just want to chime in on this issue. I've being using Stubby instead of Unbound for this exact issue. Stubby will try to reuse existing connection as much as possible, which is more performant and also saves a lot of duplicated entries on my router's NAT table. |
|
I know Stubby reuse connections. Regards |
|
I use Stubby too for reusable connections. Unbound runs as a Windows service though, which is not yet supported in Stubby, so it would be nice if Unbound added reusable connections. |
|
pfsense makes use of unbound for DNS over TLS as well. TCP session reuse would be fantastic here for applying this service internally and externally to an entire network. I am eagerly waiting for an update here as well. |
|
We plan to include connection reuse in Unbound in the coming months. Most likely not in the next new release, but in the one after that. |
|
Let me also chime in: please put it behind a yes/no flag. Using TOR with standalone connections provides a level of privacy (queries can not be correlated by the server based on originating IP anymore). (Again, talking about the server's viewpoint). |
|
The issue has been reported earlier in NLnet Labs Bugzilla: |
Hey sorry to bother but was this done? |
No. It should be in Unbound 1.11 going off what was said. |
|
Alright, thanks for quick answer |
|
Hi all, Here is an update on TLS session resumption in Unbound. We are currently developing this feature in Unbound, but it will most likely not be included in Unbound version 1.11 (or an initial 1.11.0 version) yet. However, we expect to complete TLS session resumption soon. We will keep you posted on progress this month. Thank you, -- Benno |
|
Great, thanks |
|
Hi @ralphdolmans @bjovereinder |
|
There is code in progress on the branch https://github.com/NLnetLabs/unbound/tree/stream-reuse |
|
@wcawijngaards if I would like to test, after compiling https://github.com/NLnetLabs/unbound/tree/stream-reuse, how can I do? |
|
There is no parameter, it should just work by itself. |
|
I'm testing but I see multiple connections (ESTABLISHED) to upstream (1.1.1.1 and 1.0.0.1 in my case): |
|
and, after various lookups, I receive: |
|
It is going to make one connection per thread, if you have a lot of traffic, even multiple to service thousands of queries (because cannot put that much on one connection). Perhaps you have num-threads increased? Otherwise, that would be a bug of some sort. The servfail looks like it is as well, and I would like to debug it, do you know how I can reproduce it? |
|
I made only 5 or 6 lookups to different domain, so no lots of traffic. To reproduce make tons of lookup to different domain/FQDN. |
|
FYI, unbound was compiled with If I compile/use the Master branch, I don't have issue on the same Linux machine with same config file and same options to "configure". |
|
@wcawijngaards I tested the branch, too. It works fine until the upstream servers close the connection due to timeout. (This is done by quad9, cloudflare and google) After the FIN/RST packet, I never see another packet towards the upstream servers until I restart unbound. |
|
Fixed what I think is the issue, in commit 7a211e5 Thanks for the test details! That was very helpful in finding the issue. The write event was not properly re-enabled upon struct reuse after the reused ssl stream was closed by the other side due to timeout when the stream was not in use for sending queries while the other side has the timeout. This error did not impact TCP connections (the branch also implements for TCP connections). |
|
going to test |
|
It works now! Thank you. |
|
Just for info, how long is the time out to upstream? |
|
@wcawijngaards I tested d973b75 and it works like a charm with google/cloudflare/quad9. Well done! |
|
Good to know it works! That timeout for no traffic is currently coded at 30 seconds. The server unbound talks to also has a timeout for idle connections, and that is frequently shorter, or even very short in case of heavy traffic. The upstream timeout to the server for an idle connection is currently set in code (added in the new branch) and not configurable. The downstream timeout for clients can be configured and it is |
|
I'm still testing "stream-reuse", I have some comment. As you can see there is an already "ESTABLISHED" connection to upstream (that can be "reused") but just after I make another lookup, unbound is going to create another connection to upstream. So, since the goal is to reuse connection to avoid multiple connection to upstream (or try to reduce them as much as possible), why in this case unbound is not going to reuse the already existing connection? Thank you. |
|
This happens because you have So, Unbound reuses connections, but this is a per-thread-worker reuse. It keeps a list of reusable connections per thread and then uses it if possible. IPv4, IPv6 and TCP and TLS connections. There is also a maximum number of open requests on a channel, if this is exceeded Unbound would open more connections too. This needs thousands of queries waiting to add up to a number of connections (and this is not happening to you, it seems). |
|
OK. |
|
@wcawijngaards many many thanks for this!!! This is a very great improvement for unbound. |
Hi.
First of all I want to thank you very much for your work about unbound!!
I mainly use unbound as forwarder to Cloudflare (1.1.1.1 and 1.0.0.1). So unbound listen on my Linux on port 53 and forward DNS queries to 1.1.1.1:853 via TLS (DNS over TLS). I use "forward-tls-upstream" option.
I have notice that unbound, for each new lookup, create a new connection to 1.1.1.1 on port 853 in order to process the lookup. This is tested also thanks to netstat command.
Well, on a performance point of view, I expect that if unbound will go to establish only one (or much less I mean) TLS connection to 1.1.1.1:853 (and leave it UP) the DNS queries will be processed more fastly because unbound don't need time to establish a new TLS connection each time to 1.1.1.1/1.0.0.1.
Is there the possiblity to set unbound to use one and always the same connection to 1.1.1.1:853 for all DNS over TLS queries?
If not, is there a plan to add an option to unbound in order to set what I'm asking?
Many thanks for you time.
This is the output of "netstat" command that show how many connections unbound do to DoT forwarder (Cloudflare in this case). In this example only one client is connected to unbound DNS Server (port 53):
The text was updated successfully, but these errors were encountered: