Read an Excerpt
From Chapter 10: Advanced Features and Security
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, 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...
If your operating system also permits changing that limit on a per-process basis, you can increase it using BIND 8's files substatement...
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.
BIND name servers have always done periodic housekeeping: refreshing zones the server is a slave for, for example. With BIND 8, you can now control how often these chores happen, or whether they happen at all.
Name servers older than BIND 4.9 only passively remove state entries from the cache. Before such a name server returns a record to a querier, it checks to see whether the TTL on that, report has expired. If it has, the name server starts the resolution process to find more current data. This means that a BIND4 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...
sets the cleaning interval to 120 minutes. To turn off cache cleaning entirely, use a cleaning interval of zero.
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...
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.
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...
And, as with the other maintenance intervals, the default is 60 minutes, and a setting of zero disables the periodic dumping of statistics.
Name Server Address Sorting
When you are contacting a host that has multiple network interfaces, using a particular interface may give you better performance. If the multihomed host is local and shares a network with your host, one of the multihomed host's addresses is "closer." If the multihomed host is remote, you may see better performance by using one of the interfaces instead of another, but often it doesn't matter much which address is used. In days past, net 10 (the former ARPAnet "backbone") was always closer than any other remote address. The Internet has improved drastically since those days, so you won't often see a marked improvement by preferring one network over another for remote multihomed hosts, but we'll cover that case anyway.
Before we get into address sorting by a name server, you should first look at whether address sorting by the resolver better suits your needs. (See the section called "The sortist Directive" in Chapter 6, Configuring Hosts.) Since your resolver and name server may be on different networks, it often makes more sense for the resolver to sort addresses optimally for its host. Address sorting at the name server works fairly well, but it won't be optimal for every resolver it services. Resolver address sorting was added at 4.9. If your resolver (not your name server) is older than 4.9, you are out of luck. You'll have to make do with address sorting at the name server, which was introduced in 4.8.3.
We should also mention that address sorting is not supported in BIND 8. For BIND 8, the developers removed address sorting because they believed that it had no place in the server.
Local Multihomed Hosts
Let's deal with the local multihomed host first. Suppose you have a source host (i.e., a host that keeps your master sources) on two networks, cleverly called network A and network B, and this host uses NFS to export filesystems to hosts on both networks. Hosts on network A will experience better performance if they use the source host's interface to network A. Likewise, hosts on network B would benefit from using the source host's interface to network B for the address of the NFS mount.
In Chapter 4, Setting Up BIND, we mentioned that BIND returns all the addresses for a multihomed host. There was no guarantee of the order in which 'a DNS server would return the addresses, so we assigned aliases (wh249 and wh253 for wormhole) to the individual interfaces. if one interface was preferable, you (or more realistically, a DNS client) could use an appropriate alias to get the correct address. You can use aliases to choose the "closer" interface (e.g., for setting up NFS mounts), but because of address sorting, they are not always necessary...