While using DNS proxy for TCP-based DNS there are upper limits to the number of concurrent/parallel sessions induced by two factors

By default the tcp-memory-quantum is set to 16 and the default max-large-packet-buffers is 65535

Consider a case where there are 500 DNS requests per second (tcp-based) being initiated in the presence of DNS proxy, you are likely to exhaust the above limit within 8 seconds post which new sessions would not be initiated until some of the old session are cleared (dns-proxy sessions have  4 second time-out value)

If one deems that the volume of dns-proxy sessions at a site is likely to be high enough to breach the above volume of max parallel sessions, one should consider modifying the default values of tcp-memory-quantum and max-large-packet-buffers

For starters the tcp-memory-quantum value can be changed  to 4 using the below cli configuration

Note: Currently there is no provision to configure this via Director, hence the configuration would need to applied directly on the cli/config-mode, post which you will need execute a "sync from" on the Director to sync the configuration in the appliance contex (any further template commits must be performed in "auto merge" mode to ensure this configuration is not over-written)

The other option is to set tcp-memory-quantum on the Director Cli in the device template context as below and then commit the template to the respective device

Just the above configuration will effectively increase the volume of concurrent sessions to 16K (65535/4) - this should ideally be sufficient for most use cases

However, if you deem the volume of concurrent tcp-based dns-proxy sessions in your environment may be higher than 16K, you can look to increase the packet buffer (mbuf) using the below context to change its default-value of 65535 via cli/config-mode

This configuration can also be executed on Director UI under Device template in the below context (system>configuration>service-options) - this the preferred method of executing this configuration change

However, one has to be cautious while setting the max-possible-value in the above context - it depends on the memory (RMA) on the device, so in that sense it depends on the Device/Hardware model - you can figure out the RAM memory on your system using "show system details"

Important Note: Be extremely careful while setting this value and make sure you abide by the values mentioned in the table below with reference to the RAM on the device in question. Setting a value higher than the below values can lead to the system going into a crash loop in some scenarios. For ex, if your system has 16GB RAM, you should not set the max-large-packet-buffers to a value higher than 131071

For example

Setting the max-large-packet-buffers, to the values mentioned in the table, in conjunction with tcp-memory-quantum can further increase the volume of concurrent dns-proxy sessions