named.conf.4 (2010 09)

n
named.conf(4) named.conf(4)
(BIND 9.3)
edns (Extended DNS) Determines whether the local server will attempt to use EDNS when
communicating 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, incremen-
tal 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 specified, the transfer-format
specified by the options statement
is used.
transfer-source, transfer-source-v6
Specify the IPv4 and IPv6 source address to be used for zone transfer with the remote
server, respectively. For an IPv4 remote server, only
transfer-source can be
specified. Similarly, for an IPv6 remote server, only
transfer-source-v6
can be
specified.
transfers Limits the number of concurrent inbound zone transfers from the specified server. If no
transfers clause is specified, the limit is set according to the transfers-per-ns
option.
The trusted-keys Statement
trusted-keys Statement Grammar
trusted-keys {
( domain_name flags protocol algorithm key_data ; )...
};
trusted-keys Statement Definition and Usage
The
trusted-keys statement defines DNSSEC security roots. A security root is defined when the pub-
lic key for a nonauthoritative zone is known, but cannot be securely obtained through DNS, either
because it is the DNS root zone or its parent zone is unsigned. Once a key has been configured as a
trusted key, it is treated as if it had been validated and proven secure. The resolver attempts DNSSEC
validation on all DNS data in subdomains of a security root.
The
trusted-keys statement can contain multiple key entries, each consisting of the key’s five param-
eters: domain_name (string ), flags (number), protocol (number), algorithm (number), and the base-64
representation of the key_data (string ).
HP-UX 11i Version 3: September 2010 23 Hewlett-Packard Company 23