10.4.1.1 Limiting transfers initiated per name server

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

In BIND 8, the conf file statement is:

options {
                transfers-per-ns 2;
};

The equivalent BIND 4 boot file directive is:

limit transfers-per-ns 2

With a forthcoming version of BIND 8 (we're not sure which), you'll also be able to set the limit on a server-by-server basis, instead of globally. To do this, you'd use the transfers substatement inside a server statement, where the server is the server you'd like to specify the limit for:

server 192.168.1.2 {
                transfers 2;
};

The default limit is two active zone transfers per name server. That limit may seem small, but it works. Here is what happens. Suppose your name server needs to load four zones from a remote name server. Your name server will start transferring the first two zones and wait on the third and fourth zone. After one of the first two zone transfers completes, the third zone will be requested. After another transfer completes, the fourth zone will be started. 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 want to increase this limit? You might want to increase this limit if you 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 machines is slow. This probably only matters if you're maintaining hundreds or thousands of zones. And you need to make sure that the remote name server and the networks between can handle the additional workload of more simultaneous zone transfers.

10.4.1.2 Limiting the total number of zone transfers initiated

The last limit dealt with a single remote name server. This one deals with more than one remote name server. BIND versions 4.9 and later let you limit the total number of zones your server will request at any one time. The default limit is ten. As we explained above, your server will only pull two zones from any given remote name server by default. If your server is transferring two zones from each of five name servers, your server will have hit the limit, and it will postpone any further transfers until one of the current transfers finishes.

The BIND 8 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 ten active zone transfers, you should decrease this number. If you run a server supporting 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 also 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 only start 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 will not have any effect unless the limit per server is also increased.)

10.4.1.3 Limiting the duration of a zone transfer

BIND 8 will 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 that's taking longer than 120 minutes is probably hung and won't complete, and the named-xfer process is taking up resources unnecessarily. If you'd like a smaller or larger limit, perhaps because you know that your 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 the 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 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 "db.rinkydink";
                masters { 192.168.1.2; };
                max-transfer-time-in 180;
};

10.4.1.4 More efficient zone transfers

A zone transfer, we said earlier, is composed of many DNS messages sent end-to-end over a TCP connection. Traditional zone transfers only put 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 only carrying a single record. It's like being the only person in a Chevy Suburban. A DNS message could carry many more records.

BIND 8 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 BIND 8 transfer-format subcommand controls which zone transfer format the server uses for zones that it is a master for. That is, it determines the format of the zones that your server transfers to its slaves. transfer-format is both an options subcommand and a server subcommand: as an options subcommand, transfer-format controls the server's global zone transfer behavior. The default is to use the old one-answer zone transfer format, for interoperability with BIND 4 name servers.

options {
                transfer-format many-answers;
};

changes the server's settings to use the many-answers format for all servers, unless explicitly told not to in a server statement, like this:

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 using the new format. They're more efficient from a bandwidth and CPU utilization point of view, but your zone transfers may take longer to complete.

If you'd like to take advantage of the new, more efficient zone transfers, set your server's global zone transfer format setting to many-answers, if most of your slaves run BIND 8 or Microsoft's DNS Server, which also understands the format, or 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.

10.4.2.1 Changing the data segment size limit

Some operating systems have a default limit to stop processes from using too much memory. If your OS is limiting the name server from growing to the size it wants to grow to, the name server may not operate efficiently, and it may even panic or exit. Unless your name server handles an extremely large amount of data, you won't run into this limit. But if you do, BIND 4.9 and 8 have configuration options to change the system's default limit on data segment size. You might use these options to set a higher limit than the default system limit for the named process.

For BIND 8, the statement is:

options {
                datasize size
};

For BIND 4, the directive is:

limit datasize size

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

NOTE: Not all systems support increasing the data segment size. If your system is one that does not, the name server will issue a syslog message at level LOG_WARNING to tell you that this feature is not implemented.

10.4.2.2 Changing the stack size limit

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

options {
                stacksize size;
};

where size is specified as in datasize. As with datasize, this feature only works on systems that permit modification of the stack size limit.

10.4.2.3 Changing the core size limit

If you don't appreciate named's leaving huge core files 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 only works on operating systems that support modifying the limit on core file size.

10.4.2.4 Changing the open files limit

On hosts with many IP addresses, or a low limit on the maximum number If your name server is authoritative for a lot of zones, the named process will open lots of files when it starts up - one per authoritative zone, assuming you use backup files on the zones you're a slave for. Likewise, if the host running your name server has lots of virtual network interfaces,[1] named will require one file descriptor per interface. Most UNIX operating systems place a limit on the number of files any process can open simultaneously. If your name server tries to open more files than this limit permits, you'll see this message in your syslog output:

[1] Chapter 15, Miscellaneous, describes a better solution 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 8's files substatement:

options {
                files number;
};

The default is unlimited (which is also a valid value), although this just means that the server doesn't place any limit on the number of simultaneously open files; the operating system, however, may.

10.4.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 now actively walks through the cache and removes stale records once each cleaning interval. This means that a BIND 8 name server will 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, use a cleaning interval of zero.

10.4.3.2 Interface interval

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

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.4.3.3 Statistics interval

Okay, adjusting the statistics interval - the frequency at which the BIND 8 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.