How does tcp-clients work since the fix for CVE-2018-5743

This article describes how BIND restricts the number of concurrent TCP client connections in versions that of BIND that include the fix for CVE-2018-5743. Those are Open Source versions 9.11.6-P1, 9.12.4-P1, 9.14.1 or Supported Preview Edition versions 9.11.5-S6, 9.11.6-S1 (and newer).

BIND provides a named.confoption for limiting the number of simultaneous TCP client connections (that is, the number of connections from clients to BIND as a server).

tcp-clients
The maximum number of simultaneous client TCP connections that the server will accept. The default is 100.

In BIND, a 'tcp client' is an active instance of an internal structure, intended to handle a client TCP connection. You can see how many of these currently exist at an instant in time by using the command rndc status:

In the example above, the first number is the current number of tcp clients; the second is the configured limit.

An active 'tcp client' will be either listening for new TCP connections on a server socket, or handling a received client connection for the duration of its existence.

Prior to the change for CVE-2018-5743, on starting named and with no incoming client connections, the current number of tcp clients reported by rndc would have been zero.

When running a version of BIND with the change implemented, and with named listening on a least one socket, the count of current tcp clients will be greater than zero. This is because we have changed the way that named counts tcp clients in order to be able to manage the limit upon them accurately.

As soon as you start named with any configured listening interfaces, even when there is no active connection, named will create one 'tcp client' for each configured IP address on which named is listening. You will see those in the count of current tcp clients. These clients are listening for new connections.

Note that these listeners are available for clients to use, so although named is now counting them, they don't represent active TCP connections.

Using the tools such as netstat, lsof, ss and others available in your OS environment, you can compare the TCP connections on your server with the count of 'tcp clients' as reported by rndc status. For example, on a newly-started BIND recursive resolver and using the netstat command, we can see the following listening TCP sockets - these correspond with the sample rndc status output shown earlier:

netstat -anp tcp
...
tcp4 0 0 192.0.2.20.53 . LISTEN
tcp4 0 0 127.0.0.1.53 . LISTEN
tcp6 0 0 *.53 . LISTEN

When a client does connect on one of these network interfaces, the listening 'tcp client' is used for the new connection, and a new tcp client is created and takes its place as the listener for that socket interface.

Prior to the code change for processing the tcp-clients limit, named was counting and limiting active TCP connections. This proved to be difficult to manage accurately due to BIND's internal connection-handling process flow. After the changes for CVE-2018-5743, named is instead counting and limiting 'tcp clients'.

Under the new code for managing tcp-clients , named will always maintain a minimum of one 'tcp client' per interface. This is to prevent a flood of connections on one interface from starving the other interfaces entirely, although during period of peak connectivity on one interface, there may be a period where other interfaces are more severely rate-limited.

The TCP clients limit is enforced by preventing new clients from being created. When a new connection is received and the listener for that socket interface tries to create a replacement 'tcp client' listener for itself, it will not be able to do so, thus no more new connections can be accepted on that socket. But as soon as that one (or another) connection is closed then the socket will be able to listen again.

As mentioned earlier, the minimum of one 'tcp client' per interface is still being applied, which means that under high TCP connection loads where the overall limit has been reached, each interface has at least either a 'tcp client' that is listening, or one that is handling an active connection (which, once that is closed, will resume listening for new connections).