How does tcp-clients work since the fix for CVE-2018-5743
  • 01 May 2019
  • 4 Minutes to read
  • Contributors
  • Dark
  • PDF

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

  • Dark
  • PDF

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).

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:

tcp clients: 3/150

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 . LISTEN
tcp4 0 0 . 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.

Please note that prior to the changes made to address CVE-2018-5743, the output from rndc did not include in its count, the listening tcp clients. One of the side-effects of this change has been to make them visible to the rndc status command whilst they are in listening state and before accepting new inbound client connections. On an active server, the count of current tcp connections should now never be zero.

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).

You may need a larger value for tcp-clients than you were using previously
Before the changes to named to handle the limits on simultaneous TCP connections more effectively, your servers may have been accepting more (possibly far more) TCP connections than you realised - but without any negative impact to your server's performance. After upgrading to a version of BIND with the new TCP clients limit management, you may need to increase the configured value to accommodate the true rate of client connections
'listen-on-v6 any;' may more heavily limit your IPv6 connections after the changes for CVE-2018-5743
IPv6 implementations include the possibility that a server can open a 'wildcard' socket for accepting connections on all IPv6 interfaces. BIND takes advantage of this when the host Operating System permits. Therefore if you have multiple interfaces that have active IPv6 addresses and you have opted to use listen-on-v6 any; in your named.conf, be aware that the 'at least one tcp client per interface' limit will be applied to the IPv6 wildcard socket - i.e. it is shared amongst all of your IPv6 server interfaces. It may therefore be more appropriate to configure individual listen-on-v6 options - one for each active IPv6 interface.