HP-UX Reference (11i v3 07/02) - 4 File Formats (vol 8)

n
named.conf(4) named.conf(4)
(BIND 9.3)
phrase of the server statement.
use-alt-transfer-source
Use the alternate transfer sources or not. If views are specified, this defaults to
no; other-
wise, it defaults to
yes (for BIND 8 compatibility).
The server Statement
server Statement Grammar
server ip_addr {
[ bogus yes_or_no ; ]
[ edns yes_or_no ; ]
[ keys { string ; [ string ; ]... }; ]
[ provide-ixfr yes_or_no ; ]
[ request-ixfr yes_or_no ; ]
[ transfer-format ( one-answer | many-answers ) ; ]
[ transfer-source ( ip4_addr | * )[port ip_port ] ; ]
[ transfer-source-v6 ( ip6_addr | * )[port ip_port ] ; ]
[ transfers number ; ]
};
server Statement Definition and Usage
The
server statement defines characteristics to be associated with a remote name server. The
server
statement can occur at the top level of the configuration file or inside a
view statement. If a view state-
ment contains one or more
server statements, only those apply to the view and any top-level ones are
ignored. If a view statement contains no server statements, any top-level server statements are
used as defaults.
bogus If you discover that a remote server is giving out bad data, marking it as
bogus yes will
prevent further queries to it. The default value is
bogus no.
edns (Extended DNS) Determines whether the local server will attempt to use EDNS when com-
municating with the remote server. The default is
yes.
keys Identifies a key_id defined by a key statement, to be used for transaction security when
talking to the remote server. The key statement must come before the server state-
ment that references it. When a request is sent to the remote server, a request signature
will be generated using the key specified here, and appended to the message. A request
originating from the remote server is not required to be signed by this key. Although the
grammar of the keys clause allows for multiple keys, only a single key per server is
currently supported.
provide-ixfr
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 statement is used as a default.
request-ixfr
Determines whether the local server, acting as a slave, will request incremental 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 statement 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 it possible to disable the use of IXFR even when
both master and slave claim to support it; for example, if one of the servers is defective and
crashes or corrupts data when IXFR is used.
transfer-format
The server supports two zone transfer methods. one-answer uses one DNS message per
resource record transferred. many-answers packs as many resource records as possible
into a message. many-answers is more efficient, but is only known to be understood by
BIND 9, BIND 8.x, and patched versions of BIND 4.9.5. You can specify which method to
use for a server with the transfer-format option. If transfer-format is not
254 Hewlett-Packard Company − 22 − HP-UX 11i Version 3: February 2007