dnsdist: Add warnings about large values passed to `setMaxTCPClientThreads`

diff --git a/pdns/dnsdistdist/dnsdist.cc b/pdns/dnsdistdist/dnsdist.cc
index 4186ac787575227b9535924f5a5f1da7d71d8dbc..6119e6cc9d3da80015ed9c41941f893f51ffa3bc 100644 (file)
--- a/pdns/dnsdistdist/dnsdist.cc
+++ b/pdns/dnsdistdist/dnsdist.cc
@@ -3439,7 +3439,13 @@ int main(int argc, char** argv)
        acceptor ones, otherwise we might crash when processing
        the first TCP query */
 #ifndef USE_SINGLE_ACCEPTOR_THREAD
-    g_tcpclientthreads = std::make_unique<TCPClientCollection>(dnsdist::configuration::getImmutableConfiguration().d_maxTCPClientThreads, std::vector<ClientState*>());
+    const auto maxTCPClientThreads = dnsdist::configuration::getImmutableConfiguration().d_maxTCPClientThreads;
+    /* the limit is completely arbitrary: hopefully high enough not to trigger too many false positives
+       but low enough to be useful */
+    if (maxTCPClientThreads >= 50U) {
+      warnlog("setMaxTCPClientThreads(%d) might create a large number of TCP connections to backends, and is probably not needed, please consider lowering it", maxTCPClientThreads);
+    }
+    g_tcpclientthreads = std::make_unique<TCPClientCollection>(maxTCPClientThreads, std::vector<ClientState*>());
 #endif
 
 #if defined(HAVE_DNS_OVER_HTTPS) && defined(HAVE_NGHTTP2)

diff --git a/pdns/dnsdistdist/docs/advanced/tuning.rst b/pdns/dnsdistdist/docs/advanced/tuning.rst
index 6fdef8cd22d78a2e4fcbaaa1004a6df415198d98..fd81bcf954c03b4e04656873464fc692a4642416 100644 (file)
--- a/pdns/dnsdistdist/docs/advanced/tuning.rst
+++ b/pdns/dnsdistdist/docs/advanced/tuning.rst
@@ -101,7 +101,7 @@ Before 1.4.0, a TCP thread could only handle a single incoming connection at a t
 Note that before 1.6.0 the TCP worker threads were created at runtime, adding a new thread when the existing ones seemed to struggle with the load, until the maximum number of threads had been reached. Starting with 1.6.0 the configured number of worker threads are immediately created at startup.
 
 The maximum number of threads in the TCP / DNS over TLS pool is controlled by the :func:`setMaxTCPClientThreads` directive, and defaults to 10.
-This number can be increased to handle a large number of simultaneous TCP / DNS over TLS connections.
+This number can be increased to handle a large number of simultaneous TCP / DNS over TLS connections, but the default value should already be enough for most setups.
 
 If all the TCP threads are busy, new TCP connections are queued while they wait to be picked up. The maximum number of queued connections can be configured with :func:`setMaxTCPQueuedConnections` and defaults to 1000 (10000 on Linux since 1.6.0). Note that the size of the internal pipe used to distribute queries might need to be increased as well, using :func:`setTCPInternalPipeBufferSize`.
 Any value larger than 0 will cause new connections to be dropped if there are already too many queued.

diff --git a/pdns/dnsdistdist/docs/reference/tuning.rst b/pdns/dnsdistdist/docs/reference/tuning.rst
index c6147313f121e5a61b1ddb90d40f3095142aa806..1614793ec55b2ffe4a6624c1f06e18916d91af58 100644 (file)
--- a/pdns/dnsdistdist/docs/reference/tuning.rst
+++ b/pdns/dnsdistdist/docs/reference/tuning.rst
@@ -40,6 +40,11 @@ Tuning related functions
   .. versionchanged:: 1.7.0
     The default value has been set back to 10.
 
+  .. warning::
+
+    Be wary of using a too large value for this setting. :program:`dnsdist` keeps a per-thread cache of TCP connections to its backends so using a large value could, in addition to creating a lot of threads,
+    lead to a very high number of TCP connections to the backends. PowerDNS Recursor, for example, has a low default limit (128) for the number of incoming TCP connections it is willing to accept.
+
   Set the maximum of TCP client threads, handling TCP connections. Before 1.4.0 a TCP thread could only handle a single incoming TCP connection at a time, while after 1.4.0 it can handle a larger number of them simultaneously.
 
   Note that before 1.6.0 the TCP worker threads were created at runtime, adding a new thread when the existing ones seemed to struggle with the load, until the maximum number of threads had been reached. Starting with 1.6.0 the configured number of worker threads are immediately created at startup.