Resource Use


In secure, reliability-focused environments you usually want to be able to predict the resource usage of the software used. Controlling, or at least knowing things about, typical resource usage helps keep the service stable because it has enough resources to run. It also keeps other services stable because there are still resources for them to run, and it can help prevent denial of service attacks based on exhausting limited resources. In addition, limiting how many resources one specific service can use helps prevent the other services from being taken out as a result of the attempts to take out BIND.

BIND manages a cache that, potentially, can use up all the memory on the machine on which it runs. Given a high enough query rate, BIND gladly uses all available CPU and much of the network capacity, as well. BIND manages its cache based on TTL, and nothing else. A future version of BIND 9 might implement its max-cache-size option.

Although you can restrict who you allow to send recursive queries to your nameservers, other ways are available to make something query them sending mail to your site, for example. Your mail server queries for information about the sender's hostname, then your FTP server queries about the client hostname, your Web log analyzer queries about the Web client hostnames, and so on.

However, BIND enables you to set the OS resource usage limits. If they're not set in named.conf, BIND inherits them from the invoking shell. If you use a C shell type limit to see to what the resource limits are set, or if you use a Bourne- or Korn-related shell type, such as ulimit -a, to view the resource limits, the code is as follows:

 $ ulimit -a core file size (blocks)     1000000 data seg size (kbytes)      unlimited file size (blocks)          unlimited max locked memory (kbytes)  unlimited max memory size (kbytes)    unlimited open files                  1024 pipe size (512 bytes)       8 stack size (kbytes)         8192 cpu time (seconds)          unlimited max user processes          256 Virtual memory (Kbytes)     unlimited 

Typically, the memory usage and CPU usage limits are unlimited. Several options for the options named.conf statement lets BIND adjust these values for its own private use:

coresize Limits the size of core dumps. A size of 0 prevents core dumps from filling your filesystem. It also prevents you from analyzing the core dumps to figure out what has happened when a problem occurs.
datasize The maximum size of the data segment.
files The maximum number of open files the server can have at any one time.
stacksize The size of the stack.

The downside of these limits is that you might find the limits set too low to enable BIND to operate. In that case, you can use the options to raise the limits. If your OS does not support manipulation of these limits, BIND will log warnings about it if you try to change them.

The problem with these options is that the OS might kill the named or start returning errors that are irreconcilable with continuing to run, if the limits are violated. So, if you set datasize to something reasonable for your environment and BIND later exceeds it, it might die. That might be preferable to eating your whole memory, but it requires you to run named inside a shell script loop or keep restarting BIND each time it dies:

 while :; do         named -f done 

The -f causes named to run in the foreground, so the shell will wait until named terminates before running it anew. named can also be run from init; most UNIX /etc/inittab files enable you to start, and keep restarting, system processes from it. Note, however, that most of them also keep resource usage in check by restricting how often a process is restarted. For example, if a process is restarted too often during one minute, init might stop restarting the process for five minutes, hoping whatever made it restart so often goes away. You might not want to be without your named for five minutes.

However, the cache isn't the only thing that uses memory; the zones your server is authoritative for also use memory. If you set the datasize and the zones grow, as time passes, your BIND might start using more memory than it is allowed, even when running normally. If this goes unchecked, it can in the end be killed by the OS before it completes startup. If you use datasize, or any other resource limits, you absolutely should monitor how your BIND is doing in the resource usage department and adjust the limits so that BIND stays within the limits when it runs normally.

Cache Cleaning

BIND 8 introduced a subroutine that walks the cache data structure looking for stale data. By default, it does this every 60 minutes. While this cleaning is being performed, BIND will not answer queries. If your cache server is buzzy and the cache is large (or the server slow), the interval when BIND does not answer might become larger than you want to tolerate. Then, you might want to disable cache cleaning entirely, or set it to perform less often, or even more often. You can double the interval as follows:

 options {     …     cleaning-interval 120;     … }; 

Of course, enlarging the interval or disabling cleaning entirely causes your named to use more memory. If that is a cost you can tolerate, fine. By running normal cache cleaning, the cache size should stabilize within one or two days most TTLs are one or two days, perhaps a week at the most.

If you enlarge the interval, your nameserver will still be unresponsive for a short while every interval, but it will be less often, which could well make it more tolerable. If you set the cleaning interval to 0, cleaning is disabled and stale data will be found and replaced only if the data is queried for.

One situation exists in which shortening the interval might be beneficial. If your server does not handle a lot of traffic, a relatively large percentage of the cached data might be stale at any one time. If your server is a vintage, very, very slow machine that has little memory, it will benefit it to run the cleaning subroutine more often to keep the expired items out, memory usage low, and the cache small so that the time used to do the cleaning stays low and the machine avoids swapping.

On the other hand, if you restart your named on a regular basis (twice per week or more often), all this is moot. When BIND is killed, the cache dies with it and it will not grow large between each invocation.

Zone Transfers

Two issues exist in relation to zone transfers. First of all, they are resource demanding, and second of all, some consider them to be problematic in the context of security because they help anyone locate the hosts and services in your network trivially. Knowing the names of all your hosts can help anyone with unfriendly intent guess which services your hosts run and perhaps even information about the structure of your network. This last is important, but I will not dwell on that here (see the section "Split DNS, NAT, and Network Hiding" later in this chapter). One situation in which better control of zone transfer is undeniable is in a split DNS scenario, which is also discussed later in this chapter. If you want, you can restrict zone transfers in the same way you can restrict recursive queries and queries in general. You know which servers are secondary for you, and you also know from which hosts you might want to run zone transfers by hand to perform checks or debugging. This is what the allow-transfer option is for. allow-transfer can be used in both the options statement and individual zone statements. You can also use ACLs here. A configuration might go like this:

 acl slaves {     198.162.80.1;   // Real slave     localhost;      // My self for debugging }; options {     …     allow-transfer { slaves; };     … }; 

To further control how demanding of resources zone transfers are both for you and your peers you can use three options: transfers-in, transfers-out, and transfers-per-ns. transfers-in limits how many named-xfer processes are forked concurrently to perform zone transfers. Raising this number increases memory and CPU usage. transfers-out is not implemented, but if it were, it would limit how many outgoing zone transfers BIND would allow at any one time. transfers-per-ns is a bit overlapping with transfers-in it limits how many concurrent transfers will be started with any one nameserver. These are the default values:

 options {     …     transfers-in 10;     transfers-per-ns 2;     … }; 

transfers-out does not have a default.



The Concise Guide to DNS and BIND
The Concise Guide to DNS and BIND
ISBN: 0789722739
EAN: 2147483647
Year: 1999
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net