 |  |
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;
};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:limit transfers-per-ns 2
server 192.168.1.2 {
transfers 2;
};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;
};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.)limit transfers-in 10
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;
};
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;
};
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;
};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
};
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;
};
server 192.168.1.2 {
transfer-format one-answer;
};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.
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
};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.limit datasize size
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;
};
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.
options {
coresize size;
};
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.
If your operating system also permits changing that limit on a per-process basis, you can increase it using BIND's files substatement:named[pid]: socket(SOCK_RAW): Too many open files
options {
files number;
};
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;
};
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.Sep 22 02:26:11 terminator named[13979]: client 192.249.249.151#1677: no more recursive clients: quota reached
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;
};
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;
};
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;
};
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;
};
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
};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.
|  | |
| 10.11. Avoiding a Bogus Name Server |  | 10.13. Compatibility |
