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

n
named.conf(4) named.conf(4)
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.
The
edns (Extended DNS) clause determines whether the local server will attempt to use EDNS when
communicating with the remote server. Default is "yes".
The server supports two zone transfer methods. The first,
one-answer, uses one DNS message per
resource record transferred.
many-answers packs as many resource records as possible into a mes-
sage. 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 will be used. The
transfers clause is used to limit 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
keys clause is used to identify a
key_id defined by the key statement, to be used for transaction
security when talking to the remote server. The key statement must come before the server statement
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.
trusted-keys Statement Grammar
trusted-keys {
string number number number string ;
[ string number number number string ; [...]]
};
trusted-keys Statement Definition and Usage
The
trusted-keys statement defines DNSSEC security roots. A security root is defined when the
public key for a non-authoritative 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 domain
name, flags, protocol, algorithm, and the base-64 representation of the key data.
view Statement Grammar
view
view_name [class] {
match-clients { address_match_list } ;
match-destinations { address_match_list } ;
match-recursive-only { yes_or_no } ;
[ view_option; ...]
[ zone-statistics yes_or_no ; ]
[ zone_statement; ...]
};
view Statement Definition and Usage
The view statement lets a name server answer a DNS query differently depending on who is asking. It is
particularly useful for implementing split DNS setups without having to run multiple servers. Each view
statement defines a view of the DNS namespace that will be seen by a subset of clients. A client matches
a view if its source IP address matches the
address_match_list of the view’s
match-clients
clause and its destination IP address matches the address_match_list of the view’s
match-
destinations clause.
If not specified, both
match-clients and match-destinations default to matching all
addresses. A view can also be specified as match-recursive-only, which means that only recursive
requests from matching clients will match that view. The order of the view statements is significant - a
client request will be resolved in the context of the first view that it matches.
Zones defined within a view statement will only be accessible to clients that match the view. By defining
a zone of the same name in multiple views, different zone data can be given to different clients, for exam-
ple, "internal" and "external" clients in a split DNS setup.
HP-UX 11i Version 2: September 2004 − 18 − Hewlett-Packard Company Section 4−−193