HP-UX Reference (11i v2 04/09) - 4 File Formats (vol 8)

n
named.conf(4) named.conf(4)
min-refresh-time
, max-refresh-time
,
min-retry-time
, max-retry-time
These options control the server’s behavior on refreshing a zone (querying for SOA
changes) or retrying failed transfers. Usually the SOA values for the zone are used, but
these values are set by the master, giving slave server administrators little control over
their contents.
These options allow the administrator to set a minimum and maximum refresh and retry
time either per-zone, per-view, or per-server. These options are valid for master, slave
and stub zones, and clamp the SOA refresh and retry times to the specified values.
The Statistics File
The statistics file generated by BIND 9.2 is similar, but not identical, to that generated by BIND 8. The
statistics dump begins with the line +++ Statistics Dump +++ (973798949), where the number in
parentheses is a standard Unix-style timestamp, measured as seconds since January 1, 1970. Following
that line are a series of lines containing a counter type, the value of the counter, optionally a zone name,
and optionally a view name. The lines without view and zone listed are global statistics for the entire
server. Lines with a zone and view name for the given view and zone (the view name is omitted for the
default view). The statistics dump ends with the line --- Statistics Dump --- (973798949), where the
number is identical to the number in the beginning line. The following statistics counters are main-
tained:
success The number of successful queries made to the server or zone. A successful query is
defined as query which returns a NOERROR response other than a referral response.
referral The number of queries which resulted in referral responses.
nxrrset The number of queries which resulted in NOERROR responses with no data.
nxdomain The number of queries which resulted in NXDOMAIN responses.
recursion The number of queries which caused the server to perform recursion in order to find the
final answer.
failure The number of queries which resulted in a failure response other than those above.
server Statement Grammar
server ip_addr {
[ bogus yes_or_no ; ]
[ provide-ixfr yes_or_no ; ]
[ request-ixfr yes_or_no ; ]
[ edns yes_or_no ; ]
[ transfers number ; ]
[ transfer-format ( one-answer | many-answers ) ; ]]
[ keys { string ; [ string ; [...]] } ; ]
};
server Statement Definition and Usage
The
server statement defines characteristics to be associated with a remote nameserver. The server
statement can occur at the top level of the configuration file or inside a view statement. If a view
statement contains one or more server statements, only those apply to the view and any top-level ones
are ignored. If a view contains no server statements, any top-level server statements are used as
defaults.
If you discover that a remote server is giving out bad data, marking it as "bogus" will prevent further
queries to it. Default value of bogus is "no". The
provide-ixfr clause determines whether the local
server, acting as master, will respond with an incremental zone transfer when the given remote server, a
slave, requests it. If set to "yes", incremental transfer will be provided whenever possible. If set to "no",
all transfers to the remote server will be nonincremental. If not set, the value of the provide-ixfr
option in the view or global options block is used as a default.
The
request-ixfr clause determines whether the local server, acting as a slave, will request incre-
mental zone transfers from the given remote server, a master. If not set, the value of the request-
ixfr option in the view or global options block is used as a default.
IXFR requests to servers that do not support IXFR will automatically fall back to AXFR. Therefore,
there is no need to manually list which servers support IXFR and which ones do not; the global default of
yes should always work. The purpose of the provide-ixfr and request-ixfr clauses is to make
Section 4−−192 Hewlett-Packard Company − 17 − HP-UX 11i Version 2: September 2004