Global Server Options

Other DNS Servers

The Other DNS Servers page allows you to configure the behavior of DNS servers that BIND will communicate with in one way or another in a zone transfer relationship. This allows you to explicitly configure several aspects of the transfer relationship for each server (Figure 8-2).

Figure 8-2: Configuring other servers

The first field is the IP address of the server to configure. If you are receiving zone transfers for several servers and one of them is to be treated differently, here is where to configure it. The next field tells BIND to treat replies from this server as bogus, meaning incorrect. Future results that come from this domain will not be trusted. Next, in the Zone transfer format field, you can configure whether BIND will receive zone transfers one at a time or in a batch of many. Finally, though it is not yet implemented in BIND (at least not the latest version of BIND 8 - BIND 9 may have this feature by now), there is a placeholder for a per-server limitation on the number of transfers to initiate concurrently called Maximum transfers.

Note 

If you have configured any security keys as documented later in the DNS Keys section, there will be an additional field containing a check box for each of the keys configured. Selecting one will require the server to authenticate itself using the key selected. A copy of the key must exist on both the local server and the remote server and must be configured in the BIND configuration for each.

This page configures the server directive and related options in your named.conf file. By default, no other servers are defined.

Logging and Errors

This page provides a list of existing logging channels that are active for bind. It also allows you to add new logging channels. Generally speaking, the logs provided by BIND by default are enough for most purposes, providing a general overview of operations (starting, stopping, and so on) as well as any errors that occur during operation. However, if you need additional logging or logging of specific information to a separate file, you can configure it here.

Logging in BIND 8 is very flexible but also a little confusing at first glance. To add a new log, you first create a new channel that can be set to log to a file or to a syslog level. You then configure the level of information to log there, as discussed next. Finally, you assign logging categories to that channel. The categories dictate what types of information are logged to this particular channel (Figure 8-3).

Figure 8-3: Creating a new logging channel

In the example, I've created a logging channel called test. I've chosen to send it to a log file located at /var/log/test (I know what you're thinking: 'Where does he come up with these great names?'). So far it's all pretty self-explanatory, but then we come to Minimum message level. Here we can set the logging level for the information we'd like logged. There are five presets, and you can also choose a numeric debug level. The five presets are, from order of least important, info, notice, warning, error, and critical, which are pretty much what they sound like. The info level is almost everything the server has to say about the subject, making for quite a chatty little log. On the other hand, the critical level is reserved for things that usually mean your name server is experiencing one or more serious problems, possibly leading to improper functioning of the server. These first five levels are the same as those used by syslog. The Debug level option allows you to set a debug level for debugging messages to be sent to your log. Note that debug messages cannot be sent to syslog, and must be logged to a file. Finally, the Global level sets this log to the same level as the global server logging.

Next, I assigned a logging category to the logging channel test. In this case I decided to send security information to this channel. There are currently 22 supported categories of information that can be logged. They are as follows.

Logging categories
default	If no categories are specified, then default is used. Default contains most messages from the other categories, but a few are left out.
config	Configuration file processing information. BIND writes these messages as it loads the configuration file.
parser	Configuration file parsing information. BIND writes these messages as it parses the configuration file.
queries	Logging of queries.
lame-servers	Notifies you of the detection of a bad delegation.
statistics	Provides periodic reports of general system runtime information.
Panic	Logging of problems that will cause the shutdown of the server.
update	Dynamic updates.
ncache	Negative caching.
xfer-in	Zone transfers the server is receiving.
xfer-out	Zone transfers the server is sending.
db	All database operations.
eventlib	Debugging info from the event system. Only one channel may be specified for this category, and it must be a file channel. If you do not define the eventlib category, eventlib will be directed to default. This is generally only useful to developers debugging BIND or its related libraries.
packet	Dumps of packets received and sent. Only one channel may be specified for this category, and it must be a file channel. If you do not define the packet category, it will be directed to the default category at the debug level.
notify	The NOTIFY protocol, which provides asynchronous change notifications.
cname	CNAME errors.
security	Approved and unapproved requests.
os	Problems with the underlying operating system.
Insist	Internal consistency check failures.
maintenance	Periodic maintenance events.
load	Zone loading messages.
response-checks	Messages arising from response checking, such as "Malformed response...", "wrong ans. name...", "unrelated additional info...", "invalid RR type...", and "bad referral...".

Access Control Lists

This page is for entering any number of named address match lists. The lists defined here are used later in the configuration for a number of purposes, though having an ACL by itself does nothing. To create an ACL, simply enter a name in the ACL Name field, and the addresses, networks, and other ACLs that this ACL will match in the second field. There are a few ACLs that are built in and do not need to be defined manually. These are any, which matches all hosts; none, which matches no hosts; localhost, which matches the IP address of all interfaces on the system where BIND is running; and localnets, which matches all hosts on the local networks for which the system has an interface configured.

Files and Directories

Here you configure a few of the file locations for files that your BIND process may need to read from or write to. These usually do not need to be changed, but it may be useful to know what each of them refers to.

Statistics output file

This option allows you to choose a different file name and path for the statistics that BIND generates when signaled. To cause BIND to dump statistics to this file, you can use the ndc program with the stats option, which will send the correct signal to BIND. This corresponds to the statistics-file directive in the options section of named.conf and defaults to named.stats.

Database dump file

Configures the location of the file where BIND dumps its database when it receives the correct signal. The signal can be generated by using ndc dumpdb. This option correlates to the dump-file directive in the options section of named.conf and defaults to named_dump.db.

Process ID file

This is the location of BIND's process ID file. This location and file must be writable by the BIND process.

Path to zone transfer program

This sets the path to the named-xfer program that BIND uses for inbound zone transfers. This option configures the named-xfer directive of the options section in named.conf.

Forwarding and Transfers

This page allows you to configure parent DNS servers (Figure 8-4). Here, you declare what servers your BIND can query and how to behave towards them.

Figure 8-4: Forwarding and Transfers

Servers to forward queries to

With this field, you enter any name servers that you wish your BIND process to query in the event it does not have a cached result to serve to the client. Usually this will be the name servers that your ISP or hosting service provides for you, but it may also be other servers on your local network. It's a good idea to have at least two, which will be called the primary and secondary name servers, respectively. This option configures the forwarders directive in the options section of named.conf.

Lookup directly if no response from forwarder

This option allows you to choose whether BIND should query the TLD servers directly if the forwarders do not reply. You may need to turn this off if you have a non-Internet-connected DNS server, or a server isolated by a firewall on your local network that can only communicate with the forwarders. This option configures the forward directive.

Maximum zone transfer time

This allows you to put an upper limit on the time allowed for inbound zone transfers. This option correlates to the max-transfer-time-in directive, and defaults to 120 minutes. After this time, a transfer will be terminated.

Zone transfer format

Sets the global transfer format (which can be overridden on a per server basis, in the Other Servers section). Here you can choose whether BIND should receive a message for each resource record transferred. The many choice tells BIND to accept several per message, which is more efficient. This option correlates to the transfer-format directive.

Maximum concurrent zone transfers

Places a limit on the number of concurrent transfers. This corresponds to the transfers-in option and defaults to 10. Increasing this may improve performance but at the cost of more system resources being consumed.

Addresses and Topology

The following options specify network-specific details:

Ports and addresses to listen on

BIND can answer on any number of ports and addresses on your server. By default, BIND will answer on port 53 on every active IP address. If you choose to listen on one or more specific addresses and/or ports, then BIND will answer on only those allowed by the match list. It is also possible to negate a port or IP by prepending an !.

Source IP address for queries

If your BIND does not know the answer to a query, it will query other name servers. Here you can define the local addresses and ports on which to query those name servers. By default it can use any IP or port that is available on the system.

Nameserver choice topology

When querying other servers, BIND can be configured to choose name servers that are closer in the topology address list. The order the servers appear in the list indicates their distance from the local name server, where the first is closest and the last is furthest. It is also possible to force one or more name servers to be last resorts, by prepending them with !. Those servers prepended by an exclamation point will be placed at the end of the queue, regardless of placement in the topology address list.

Miscellaneous Options

The BIND options with no other obvious locations ended up in this section, so it has a relatively large number of options. Luckily for you, most administrators don't have to worry about these options very often. Unluckily for me, to achieve my goal of fully documenting the BIND module, I have to document these features just as completely as those that are more often used. So, on this page you'll find several configurable memory usage settings, some timing options, and some general behavior choices.

Maximum core dump size

This is the maximum file size of a dump file that BIND will generate in the event of a crash. This option configures the coresize option in the named.conf file. Your operating system may also impose a limit on core size, which may or may not be smaller than the value configured here.

Maximum data memory usage

This defines the maximum amount of memory that BIND will use for storage of data. This is not the complete memory usage of BIND, as the process itself must have memory, but it can be used to limit BIND somewhat. This option correlates to the datasize in named.conf.

Maximum open files

Defines the number of files that BIND can have open at any given time. The default is the limit of the OS; however, BIND is not always able to determine this at runtime if the operating system does not accurately report it. In this case, it may be necessary to use the correct value here. This is not a problem under the most popular operating systems where Webmin and BIND are used, such as FreeBSD and Linux. This option configures the files directive.

Maximum stack memory usage

Defines the maximum amount of stack space that the BIND process may use. This correlates to the stacksize directive.

Interval between cleaning expired records

BIND will periodically remove expired records from the cache. This option configures how often this cleaning occurs. This corresponds to the cleaning-interval and defaults to 60 minutes.

Interval between check for new interfaces

BIND will scan the network interface list periodically, and this option configures the interval, in minutes, between scans. The default is 60 minutes. This option configures the interface-interval directive.

Interval between logging stats

This setting controls how often BIND writes general server statistics to the logs. By default this occurs every 60 minutes, and if set to 0 statistics logging will be turned off. This option correlates to the statistics-interval directive.

Do full recursive lookups for clients?

BIND can respond in one of two ways if it does not have an answer for a client. If this option is set to Yes, the default, then BIND will perform the lookup itself on a parent or root server. If this is turned off, BIND will simply refer the client to another name server that can answer the query. This option configures the recursion directive.

Allow multiple CNAME aliases for one name?

Older versions of BIND allowed multiple CNAME resource records for a single domain, and many sites used this for load balancing. However, this usage is against standards and is not recommended. Turning this on allows you to use multiple CNAMES, as in older versions of BIND. The default is off, and it correlates to the multiple-cnames directive.

Fetch glue records?

If this option is set to Yes, the default, the server will fetch 'glue' resource records it does not have when constructing the additional data section of a response. Setting this to No can be used in conjunction with recursion no to prevent the server's cache from growing or becoming corrupted. However, doing this increases the work for the client. This option configures the fetch-glue directive.

Set authoritative AA bit on responses?

BIND normally caches negative responses (i.e., NXDOMAIN, or 'this does not exist'), however, some very old servers and clients may have problems with this and generate errors. It's probably wise to upgrade those old clients and servers rather than turning this off. This option configures the auth-nxdomain directive and defaults to Yes.