Table of Contents for

Squid: The Definitive Guide

Synopsis

This directive is meaningful only with the —disable-internal-dns option.

The interface between Squid and the external DNS program is built around the gethostbyname( ) function. Squid writes a request to a dnsserver process, which performs the query. The gethostbyname( ) call blocks the process until the reply arrives. This is why Squid can’t use the function internally.

Each dnsserver handles only one request at a time, so you need enough of them to handle the load from your cache. Unfortunately, you may need to experiment with different values to discover the appropriate setting for your particular situation. In theory, you can calculate the number of child processes if you know the rate of DNS lookups and how long lookups take on average. Unfortunately, both values can vary significantly over time.

Squid writes a warning into cache.log if you have too few dnsserver child processes. If all helper processes are busy, Squid queues up new lookups. If the queue grows too large, Squid emits an error message and exits. Thus, too many child processes are better than too few.

You can use the dns entry in the cache manager menu to see dnsserver utilization information. Requests are always sent to the first idle process, so you can see if some processes never receive any DNS lookup requests. In that case you may want to lower the dns_children value.

Why doesn’t Squid just create and destroy child processes as necessary? The primary reason is that the creation of a child process, via fork( ), is a relatively “heavy” operation. It may introduce significant delays for active HTTP requests. A Squid process typically consumes a lot of memory. In some cases, fork( ) may fail due to lack of available memory or swap space. Rather than try to fix all these issues with the external DNS implementation, Squid can read and write DNS messages internally.

dns_children number

dns_children 5

dns_children 16