System Tuning (DNS and BIND, 4th Edition)

10.12. System Tuning

While for many name servers BIND's default configuration values work just fine, yours may be one of those that need some further tuning. In this section, we discuss all the various dials and switches available to you to tune your name server.

10.12.1. Zone Transfers

Zone transfers can place a heavy load on a name server. On BIND 4 name servers, outbound zone transfers (transfers of a zone the server is master for) require fork( ) ing the named process, thereby using a significant amount of extra memory. BIND 4.9 introduced mechanisms for limiting the zone transfer load that your name server places on its master servers. BIND 8 and 9 have these mechanisms and more.

10.12.1.1. Limiting transfers requested per name server

With BIND 4.9 and later, you can limit the number of zones your name server requests from a single remote name server. This will make the administrator of the remote name server happy because his host won't be pounded for zone transfers if all of the zones change -- important if hundreds of zones are involved.

In BIND 8 and 9, the config file statement is:

options {
	transfers-per-ns 2;
};

The equivalent BIND 4 boot file directive is:

limit transfers-per-ns 2

In BIND 9, you can also set the limit on a server-by-server basis instead of globally. To do this, use the transfers substatement inside a server statement, where the server is the name server you'd like to specify the limit for:

server 192.168.1.2 {
	transfers 2;
};

This overrides any global limit set in the options statement. The default limit is two active zone transfers per name server. That limit may seem small, but it works. Here's what happens: suppose your name server needs to load four zones from a remote name server. Your name server starts transferring the first two zones and wait to transfer the third and fourth zones. After one of the first two zone transfers completes, the name server begins transferring the third zone. After another transfer completes, the name server starts transferring the fourth zone. The net result is the same as before there were limits -- all the zones are transferred -- but the work is spread out.

When might you need to increase this limit? You might notice that it is taking too long to synch up with the remote name server, and you know that the reason is the serializing of transfers -- not just that the network between the hosts is slow. This probably matters only if you're maintaining hundreds or thousands of zones. You also need to make sure that the remote name server and the networks in between can handle the additional workload of more simultaneous zone transfers.

10.12.1.2. Limiting the total number of zone transfers requested

The last limit dealt with the zone transfers requested from a single remote name server. This limit deals with multiple remote name servers. BIND Versions 4.9 and later let you limit the total number of zones your name server can request at any one time. The default limit is 10. As we explained previously, your name server will pull only two zones from any single remote server by default. If your name server is transferring two zones from each of five remote servers, your server has hit the limit and will postpone any further transfers until one of the current transfers finishes.

The BIND 8 and 9 named.conf file statement is:

options {
	transfers-in 10;
};

The equivalent BIND 4 boot file directive is:

limit transfers-in 10

If your host or network cannot handle 10 active zone transfers, you should decrease this number. If you run a server that supports hundreds or thousands of zones and your host and network can support the load, you might want to raise this limit. If you raise this limit, you may also need to raise the limit for the number of transfers per name server. (For example, if your name server loads from only four remote name servers and your name server will start only two transfers per remote name server, then your server will have at most eight active zone transfers. Increasing the limit for the total number of zone transfers won't have any effect unless you also increase the per-name server limit.)

10.12.1.3. Limiting the total number of zone transfers served

BIND 9 name servers can also limit the number of zone transfers they'll serve simultaneously. This is arguably more useful than limiting the number you'll request, since without it you'd have to rely on the kindness of the administrators who run your slave name servers not to overload your master server. The BIND 9 statement is:

options {
	transfers-out 10;
};

The default limit is 10.

10.12.1.4. Limiting the duration of a zone transfer

BIND 8 and 9 also let you limit the duration of an inbound zone transfer. By default, zone transfers are limited to 120 minutes, or two hours. The idea is that a zone transfer taking longer than 120 minutes is probably hung and won't complete, and the process is taking up resources unnecessarily. If you'd like a smaller or larger limit, perhaps because you know that your name server is a slave for a zone that normally takes more than 120 minutes to transfer, you can use this statement:

options {
	max-transfer-time-in 180;
};

You can even place a limit on transfers of a particular zone by using the max-transfer-time-in substatement inside a zone statement. For example, if you know that the rinkydink.com zone always takes a long time (say three hours) to transfer, either because of its size or because the links to the master name server are so slow, but you'd still like a shorter time limit (maybe an hour) on other zone transfers, you could use:

options {
	max-transfer-time-in 60;
};

zone "rinkydink.com" {
	type slave;
	file "bak.rinkydink.com";
	masters { 192.168.1.2; };
	max-transfer-time-in 180;
};

In BIND 9, there's also a max-transfer-time-out substatement that can be used the same way (either within an options statement or a zone statement). It controls how long an outbound zone transfer (i.e., a transfer to a slave) can run and has the same default value (120 minutes) as max-transfer-time-in.

BIND 9 name servers even let you limit zone transfer idle time, the length of time since the zone transfer made any progress. The two configuration substatements, max-transfer-idle-in and max-transfer-idle-out, control how long an inbound and an outbound zone transfer can be idle, respectively. Like the transfer time limits, both can be used as either an options substatement or a zone substatement. The default limit on idle time is 60 minutes.

10.12.1.5. Limiting the frequency of zone transfers

It's possible to set a zone's refresh interval so low as to cause slave name servers for that zone undue work. For example, if your name server is a slave for thousands of zones and the administrators of some of those zones set their refresh intervals to very small values, your name server may not be able to keep up with all the refreshing it needs to do. (If you run a name server that's a slave for that many zones, be sure to read the later section "Limiting the number of SOA queries"; you may also need to tune the number of SOA queries allowed.) On the other hand, it's possible for an inexperienced administrator to set her zone's refresh interval so high as to cause prolonged inconsistencies between the zone's primary master and slave name servers.

BIND Versions 9.1.0 and later let you limit the refresh interval with max-refresh-time and min-refresh-time. These substatements bracket the refresh value for all master, slave, and stub zones if used as an options substatement, or just for a particular zone if used as a zone substatement. Both take a number of seconds as an argument:

options {
	max-refresh-time 86400;    // refresh should never be more than a day
	min-refresh-time 1800;     // or less than 30 minutes
};

BIND 9.1.0 and later name servers also let you limit the retry interval with the max-retry-time and min-retry-time substatements, which use the same syntax.

10.12.1.6. More efficient zone transfers

A zone transfer, as we said earlier, is composed of many DNS messages sent end-to-end over a TCP connection. Traditional zone transfers put only a single resource record in each DNS message. That's a waste of space: you need a full header on each DNS message, even though you're carrying only a single record. It's like being the only person in a Chevy Suburban. A TCP-based DNS message couldcarry many more records: its maximum size is a whopping 64 KB!

BIND 8 and 9 name servers understand a new zone transfer format, called many-answers. The many-answers format puts as many records as possible into a single DNS message. The result is that a many-answers zone transfer takes less bandwidth because there's less overhead, and less CPU time because less time is spent unmarshaling DNS messages.

The transfer-format substatement controls which zone transfer format the name server uses for zones for which it is a master. That is, it determines the format of the zones that your name server transfers to its slaves. transfer-format is both an options substatement and a server substatement; as an options substatement, transfer-format controls the name server's global zone transfer format. BIND 8's default is to use the old one-answer zone transfer format for interoperability with BIND 4 name servers. BIND 9's default is to use the many-answers format. The statement:

options {
	transfer-format many-answers;
};

changes the name server's settings to use the many-answers format for zone transfers to all slave servers, unless a server statement like the following explicitly says otherwise:

server 192.168.1.2 {
	transfer-format one-answer;
};

The one downside to using the many-answers format is that zone transfers can actually take longer to complete using the new format, despite being more efficient from a bandwidth and CPU utilization point of view.

If you'd like to take advantage of the new, more efficient zone transfers, do one of the following:

Set your name server's global zone transfer format to many-answers (or don't add one at all if you're running BIND 9) if most of your slaves run BIND 8, BIND 9, or Microsoft's DNS Server, which also understands the format.
Set your name server's global zone transfer format to one-answer, if most of your slaves run BIND 4. Then use the transfer-format server substatement to adjust the global setting for exceptional servers.

Remember that if you run BIND 9, you'll need to add an explicit server statement for all BIND 4 slaves to change their transfer formats to one-answer.

10.12.2. Resource Limits

Sometimes you just want to tell the name server to stop being so greedy: don't use more than this much memory, don't open more than this many files. BIND 4.9 introduced these limits, and, as with so many features, BIND 8 and 9 give you several new variations.

10.12.2.1. Changing the data segment size limit

Some operating systems place a default limit on the amount of memory a process can use. If your OS ever prevents your name server from allocating additional memory, the server will panic or exit. Unless your name server handles an extremely large amount of data or the limit is very small, you won't run into this limit. But if you do, BIND 4.9 and 8 as well as BIND 9.1.0 and later name servers have configuration options to change the system's default limit on data segment size. You might use these options to set a higher limit for named than the default system limit.

For BIND 8 and 9, the statement is:

options {
	datasize size          
};

For BIND 4, the directive is:

limit datasize size

size is an integer value, specified in bytes by default. You can specify a unit other than bytes by appending a character: k (kilobyte), m (megabyte), or g (gigabyte). For example, "64m" is 64 megabytes.

TIP: Not all systems support increasing the data segment size for individual processes. If your system doesn't, the name server will issue a syslog message at level LOG_WARNING to tell you that this feature is not implemented.

10.12.2.2. Changing the stack size limit

In addition to allowing you to change the limit on the size of the name server's data segment, BIND 8 and BIND 9.1.0 and later name servers let you adjust the limit the system places on the amount of memory the named process's stack can use. The syntax is:

options {
	stacksize size;
};

where size is specified as in datasize. Like datasize, this feature works only on systems that permit a process to modify the stack size limit.

10.12.2.3. Changing the core size limit

If you don't appreciate named 's leaving huge core files lying around on your filesystem, you can at least make them smaller by using coresize. Conversely, if named hasn't been able to dump an entire core file because of a tight operating system limit, you may be able to raise that limit with coresize.

coresize's syntax is:

options {
	coresize size;
};

Again, as with datasize, this feature works only on operating systems that let processes modify the limit on core file size, and doesn't work on versions of BIND 9 before 9.1.0.

10.12.2.4. Changing the open files limit

If your name server is authoritative for a lot of zones, the named process opens lots of files when it starts up -- one per authoritative zone, assuming you use backup zone data files on the zones you're a slave for. Likewise, if the host running your name server has lots of virtual network interfaces,[79] named requires one file descriptor per interface. Most Unix operating systems place a limit on the number of files any process can open concurrently. If your name server tries to open more files than this limit permits, you'll see this message in your syslog output:

[79]Chapter 14, "Troubleshooting DNS and BIND", describes better solutions to the "Too many open files" problem than bumping up the limit on files.

named[pid]: socket(SOCK_RAW): Too many open files

If your operating system also permits changing that limit on a per-process basis, you can increase it using BIND's files substatement:

options {
	files number;
};

The default is unlimited (which is also a valid value), although this just means that the name server doesn't place a limit on the number of concurrently open files; the operating system may, however. And though we know you're sick of our saying it, BIND 9 doesn't support this until 9.1.0.

10.12.2.5. Limiting the number of clients

BIND 9 gives you the ability to restrict the number of clients your name server will serve concurrently. You can apply a limit to the number of recursive clients (resolvers plus name servers using your name server as a forwarder) with the recursive-clients substatement:

options {
	recursive-clients 10;
};

The default limit is 1000. If you find your name server refusing recursive queries and logging, as shown by an error message like this one:

Sep 22 02:26:11 terminator named[13979]: client 192.249.249.151#1677: no more 
recursive clients: quota reached

you may want to increase the limit. Conversely, if you find your name server struggling to keep up with the deluge of recursive queries it receives, you could lower the limit.

You can also apply a limit to the number of concurrent TCP connections your name server will process (for zone transfers and TCP-based queries) with the tcp-clients substatement. TCP connections consume considerably more resources than UDP because the host needs to track the state of the TCP connection. The default limit is 100.

10.12.2.6. Limiting the number of SOA queries

BIND 8.2.2 and later name servers let you limit the number of outstanding SOA queries your name server allows. If your name server is a slave for thousands of zones, it may have many queries for the SOA records of those zones pending at any one time. Tracking each of those queries requires a small but finite amount of memory, so by default BIND 8 name servers limit outstanding SOA queries to four. If you find that your name server can't keep up with its duties as a slave, you may need to raise the limit with the serial-queries substatement:

options { 
	serial-queries 1000;
};

serial-queries is obsolete in BIND 9. BIND 9 limits the rate at which serial queries are sent (to 20 per second), not the number of outstanding queries.

10.12.3. Maintenance Intervals

BIND name servers have always done periodic housekeeping, such as refreshing zones for which the server is a slave. With BIND 8 and 9, you can now control how often these chores happen or whether they happen at all.

10.12.3.1. Cleaning interval

Name servers older than BIND 4.9 only passively remove stale entries from the cache. Before such a name server returns a record to a querier, it checks to see whether the TTL on that record has expired. If it has, the name server starts the resolution process to find more current data. This means that a BIND 4 server may cache a lot of records in a flurry of name resolution and then just let those records spoil in the cache, taking up valuable memory even though the records are stale.

BIND 8 and 9 actively walk through the cache and remove stale records once per cleaning interval. This means that BIND 8 and 9 name servers tend to use less memory for caching than a BIND 4 server in the same role. On the other hand, the cleaning process takes CPU time, and on very slow or very busy name servers, you may not want it running every hour.

By default, the cleaning interval is 60 minutes. You can tune the interval with the cleaning-interval substatement to the options statement. For example:

options {
	cleaning-interval 120;
};

sets the cleaning interval to 120 minutes. To turn off cache cleaning entirely, set the cleaning interval to zero.

10.12.3.2. Interface interval

We've said already that BIND, by default, listens on all of a host's network interfaces. BIND 8 and 9 name servers are actually smart enough to notice when a network interface on the host they're running on comes up or goes down. To do this, they periodically scan the host's network interfaces. This happens once each interface interval, which is 60 minutes by default. If you know that the host your name server runs on has no dynamic network interfaces, you can disable scanning for new interfaces to avoid the unnecessary hourly overhead by setting the interface interval to zero:

options {
	interface-interval 0;
};

On the other hand, if your host brings up or tears down network interfaces more often than every hour, you may want to reduce the interval.

10.12.3.3. Statistics interval

Okay, adjusting the statistics interval -- the frequency with which the BIND 8 name server dumps statistics to the statistics file -- won't have much effect on performance. But it fits better here, with the other maintenance intervals, than anywhere else in the book.

The syntax of the statistics-interval substatement is exactly analogous to the other maintenance intervals:

options {
	statistics-interval 60;
};

And as with the other maintenance intervals, the default is 60 minutes and a setting of zero disables the periodic dumping of statistics. Because BIND 9 doesn't write statistics to syslog, it doesn't have a configurable statistics interval either.

10.12.4. TTLs

Internally, BIND has trimmed TTL values on cached records to reasonable values for some time. BIND 8 and 9 name servers make the limits configurable.

In BIND 8.2 or later name servers, you can limit the TTL on cached negative information with the max-ncache-ttl options substatement. This was designed as a safety net for people who upgraded to 8.2 and its new negative caching scheme (RFC 2308 and all that, described in Chapter 4, "Setting Up BIND"). This new name server caches negative information according to the last field of the zone's SOA record, and many zone admins still use that field for the default TTL for the zone -- probably much too long for negative information. So a prudent name server administrator can use a substatement like:

options {
	max-ncache-ttl 3600;  // 3600 seconds is one hour
};

to trim larger negative caching TTLs to one hour. The default is 10800 seconds (three hours). Without this precaution, it's possible that someone looking up a brand-new record could get a negative answer (maybe because the new record hadn't yet reached the zone's slaves), and her name server would cache that answer for an inordinately long time, rendering the record unresolvable.

BIND 9 name servers also let you configure the upper limit of the TTL on cached records with the max-cache-ttl substatement. The default is one week. BIND 8 name servers trim TTLs to one week, too, but they don't let you configure the limit.

Finally, there's what's referred to as the lame TTL , which isn't really a TTL at all. Instead, it's the amount of time your name server remembers that a given remote name server isn't authoritative for a zone that's delegated to it. This prevents your name server from wasting valuable time and resources asking that name server for information about a domain name it knows nothing about. BIND 8 name servers after 8.2 and BIND 9 name servers newer than 9.1.0 let you tune the lame TTL with the lame-ttl options substatement. The default lame TTL is 600 seconds (10 minutes), with a maximum of 30 minutes. You can even turn off the caching of lame name servers with a value of zero, though that strikes us as a Very Bad Thing.