The Housekeeping of BIND

BIND has a few housekeeping routines. The dial-up heartbeat-interval has already been covered in Chapter 10, "DNS and Dial-Up Connections," and the cleaning-interval was covered in Chapter 8, "Security Concerns."

Interface Scanning

Every 60 minutes BIND scans your system for new interfaces, and if it finds any, it starts listening on port 53 (TCP and UDP) on the interfaces. If your machine takes interfaces up and down often, 1 hour might be too long to wait for this. The interface-interval option can help:

 options {     …     interface-interval 0;     … }; 

The interval is measured in minutes. If interface-interval is set to 0, as in this example, the interfaces are scanned only each time the named.conf file is read at reload or reconfig. At the interface scanning, any deleted interfaces also are cleaned up. If you use the query-source option and the interface identified by it is deleted, named panics and exits.

Of course, all this is moot if you use listen-on options or don't take network interfaces up and down frequently.

Zone Transfers

The main points of zone transfers are covered earlier in this book, but some things were left out.

BIND 8 performs zone transfers with the help of the external program, named-xfer. You can set the path of named-xfer with the named-xfer option. BIND 9, in contrast, performs zone transfers internally in named.

Faster Zone Transfers

Old zone transfers used a format now called one-answer, meaning one answer per network packet. This is not quite optimal, but is necessary for compatibility with old versions of BIND and named-xfer. many-answers packs each message with resource records but is understood only by BIND 8.1 or later, as well as special patched versions of BIND 4.9.5. The option is transfer-format, and it can be used globally or per server:

 options {     …     transfer-format many-answers;     … }; server 192.168.0.2 {     transfer-format one-answer; // Old server };

Zone Transfer Limits

Options are available to adjust quite a few other things about zone transfers. This code shows the default values, except for the server clause:

 options {     …     transfers-in 10;     transfers-out ?;     transfers-per-ns 2;     transfer-source 0.0.0.0;     max-transfer-time-in 120;     serial-queries 4;     … }; server 192.168.0.2 {     transfers 10;       // Really super server! }; 

transfers-in defaults to 10 and cannot be set higher than 20. transfers-out, on the other hand, is not implemented. transfers-per-ns is 2 by default. Setting the maximum number of transfers higher, globally or per server, enables the zones to be copied more quickly. This is possible only if enough bandwidth is available, but it also can use a lot of resources on both hosts. Recall that BIND 8 uses an external program to perform zone transfers. Executing the external program is quite expensive, and it uses some memory.

transfer-source is similar to the query source option. By default, zone transfer requests appear to be coming from the interface closest to the master server. If the master server uses an allow-transfer option to limit who gets to make transfers, you must perform zone transfers from the correct interface.

max-transfer-time-in is measured in minutes and sets how long named will wait for a zone to transfer before aborting it. Almost any reasonable zone should be capable of transferring in two hours, even over a 9600bps modem. Temporary network problems, such as packet loss, routing loops, back-hoe operator errors, and so on, can cause a zone transfer to fail and then revert to its usual snappy self when the network is restored. If network problems affect enough of the zone transfers, 10 halted incoming transfers can block all other zone transfers for many hours. Setting transfers-in high and transfers-per-ns low (as is the default) helps this by letting a downed network link block only 2 (by default, that is) of the incoming transfer slots.

serial-queries controls how many concurrent SOA queries a slave server will leave outstanding when checking whether zone transfers are necessary. Each outstanding query uses a small amount of memory. If the server is slave to many (hundreds or thousands) of zones, you should raise this; otherwise, it won't get enough SOA queries out to even discover that the zones have been outdated.

Manual Zone Transfers

Few reasons exist to perform manual zone transfers, but should you need to, it is quite simple:

 $ named-xfer Usage error: no domain Usage: named-xfer         -z zone_to_transfer         -f db_file         [-i ixfr_file]         [-s serial_no]         [-d debug_level]         [-l debug_log_file]         [-t trace_file]         [-p port]         [-S] [-Z]         [-C class]         [-x axfr-src]         [-T tsig_info_file]         servers [-ixfr|-axfr]… $ named-xfer -z penguin.bv -f sz/penguin.bv ns.penguin.bv named-xfer[3814]: send AXFR query 0 to 192.168.55.2 

Afterward, the zone is in sz/penguin.bv, just as if named did it itself. To get the zone loaded, restart your named. The normal way to reload slave zones is to perform a zone transfer.

You can use other methods to copy zone files, such as rcp, scp (an ssh utility), rdist, or rsync. If this is your mode of zone transfer, you must not have any masters for each zone. In addition, it might even be easiest to tell your slave server that it is master for the zones. Using tools such as scp, rdist, or rsync combined with scp provides a very secure method of transferring zones. However, BIND 9 can use TSIG for zone transfers you can't get more secure than that. On the other hand, scp does use private/public key pairs, which can make key management easier.

Incremental Zone Transfers

IXFR was introduced in RFC 1995. It allows the DNS servers to transfer the changes made to a zone instead of the whole zone, which saves time and bandwidth and is an excellent idea.

BIND 8 can maintain an IXFR database, if and only if you maintain your zones by dynamic DNS protocol, such as is achieved with the command-line tool nsupdate.

IXFR is a new protocol and a new feature in BIND. Unfortunately, the code associated with IXFRs in BIND 8.2.2P5 is too buggy to use and was not even meant to keep an IXFR database but it does, due to a bug. However, I trust that the code will mature.

The reason the IXFR database is maintained only if you manage your zone by dynamic DNS is that finding the changes between two versions of a zone is easier if you are told what the changes are. This is what we tell named with DDNS. Finding the difference between two versions of the zone file, on the other hand, is more subtle and harder to do.

The following are options to control IXFR issues:

 options {     …     maintain-ixfr-base yes;     max-ixfr-log-size ?;     … }; 

I can't think of a reason to disable keeping IXFR databases, unless they are known to be buggy. The max-ixfr-log-size option is not implemented but will limit the size of the IXFR database, which is beneficial because transferring an IXFR database larger than the zone itself is useless. BIND 8.2.2P5 does implement a limit on the IXFR database, but it's undocumented and not user-tunable.

The default for maintain-ixfr-base in BIND 8.2.2P5 was supposed to be no.

Statistics

BIND computes statistics. BIND injects three lines of statistics into the log every statistics interval (the lines have been wrapped to fit on the page):

 Aug 13 07:16:09 ns named[17871]: USAGE 966143769 965983563         CPU=25.27u/16.68s CHILDCPU=4.05u/2.83s Aug 13 07:16:09 ns named[17871]: NSTATS 966143769 965983563 A=64872         CNAME=51 SOA=1641 PTR=24273 MX=1773 TXT=33 AAAA=365 SRV=7         AXFR=5 ANY=1494 Aug 13 07:16:09 ns named[17871]: XSTATS 966143769 965983563 RR=11076         RNXD=766 RFwdR=6192 RDupR=9 RFail=74 RFErr=0 RErr=14 RAXFR=5         RLame=191 ROpts=0 SSysQ=4112 SAns=90404 SFwdQ=5214 SDupQ=2864         SErr=1 RQ=97527 RIQ=24 RFwdQ=5214 RDupQ=19 RTCP=3110 SFwdR=6192         SFail=204 SFErr=0 SNaAns=18049 SNXD=3216 

Each line starts with two timestamps: The first is now (or at least when the log line was written), in seconds since the epoch. The second is the time when named started. Subtracting the second from the first yields the wall-clock time named has been running, which is about 44 hours in this case.

The USAGE line tells how much CPU time named has used: 25.27 user seconds and 16.68 system seconds. CHILDCPU shows how much of that time was used by named children; named-xfer is the only child named runs, so it's the CPU usage for zone transfers.

The NSTATS line indicates the how many of each query type your server has received. Any query types not received are not listed.

The XSTATS line is more difficult to decipher. This is the meaning of the fields:

Field	Number of
RR=11076	Responses received.
RNXD=766	Received NXDOMAIN (no existent domain) responses.
RFwdR=6192	Received and forwarded responses. In other words, the response was sent back to the original querier.
RDupR=9	Received duplicate responses. When a query times out because of network problems, for example, it is sent again. If the original query, or the answer, was delayed not lo and the original answer then arrives (followed by the answer to the retried query), a duplicate response results.
RFail=74	Received SERVFAIL responses. A server sends this when it thinks it should have managed to answer the query but couldn't.
RFErr=0	Received FORMERRs. The remote server thought our query had a format error.
RErr=14	Received errors that were not SERVFAIL or FORMERR.
RAXFR=5	Received AXFRs.
RLame=191	Lame delegations found.
ROpts=0	Received packets with IP options set. This should be 0.
SSysQ=4112	Sent system queries. A system query is a query initiated by the server itself. For example, when the server starts, it asks around for the root servers and to measure the RTT.
SAns=90404	Sent answers. How many queries answers were sent for.
SFwdQ=5214	Sent forwarded queries. Queries received that we have forwarded.
SDupQ=2864	Sent duplicate queries. As mentioned earlier, after a timeout, the query is sent again.
SErr=1	Send errors. The number of sendto() calls that have failed.
RQ=97527	Received queries.
RIQ=24	Received inverse queries. Inverse queries are obsolete and unsupported, but some old versions of nslookup still use them. When this stays at 0 for lengthy periods, the world will be a better place.
RFwdQ=5214	The number of RQs received that needed further processing. This reflects the number of recursive clients the server has.
RDupQ=19	Received duplicate queries. This happens when the recursive clients times out and retries the query.
RTCP=3110	Received TCP queries. Some of these are AXFRs; the rest are probably reissued, truncated UDP queries.
SFwdR=6192	Number of responses forwarded to queriers.
SFail=204	Sent SERVFAIL responses.
SFErr=0	Sent FORMERR responses.
SNaAns=18049	Sent non-authoritative answers.
SNXD=3216	Sent NXDOMAIN answers.

That is a lot of statistics. But wait, there is more. You can dump this to a file, as well. ndc stats dumps the file named.stats to named's directory. If you have enabled host-statistics, it will show statistics about each and every host it has ever answered a query from, or sent a query to, since it was (re)started. A statistics file should be capable of being put into a statistics package or a performance analysis tool, to track the server's performance not that I know of any such tools. You can override the name of this file with the statistics-file option.

These host statistics can be used to track down problems with specific clients or servers. Together with a cache dump (ndc dumpdb, see Chapter 6, "Troubleshooting DNS"), this is a lot of information, perhaps too much, to base detective work on.

One statistic that is easy to understand and keep an eye on is the RQ. It gives you a way to track the query rate on your server. However, it is, perhaps, more important to track the load on your server.

Memory Statistics

If you enable deallocate-on-exit, named will want to write some memory statistics to file. The default name for this file is named.memstats. It can be overridden with the memstatistics-file option. This is most useful if you're trying to debug a memory leak in named.