named.conf.4 (2010 09)

n
named.conf(4) named.conf(4)
(BIND 9.3)
use-alt-transfer-source
See the description in The options Statement section.
zone-statistics
If yes, the server will keep statistical information for this zone, which can be dumped to
the statistics-file
defined in the server options.
Dynamic Update Policies
BIND 9.3 supports two alternative methods of granting clients the right to perform dynamic updates to a
zone, configured by the
allow-update and
update-policy options, respectively.
The
allow-update clause works the same way as in previous versions of BIND. It grants given clients
the permission to update any record of any name in the zone.
The
update-policy
clause is new in BIND 9.3 and allows more fine-grained control over what updates
are allowed. A set of rules is specified, where each rule either grants or denies permissions for one or
more names to be updated by one or more identities. If the dynamic update request message is signed
(that is, it includes either a TSIG or SIG(0) record), the identity of the signer can be determined.
Rules are specified in the
update-policy zone option, and are only meaningful for master zones.
When the
update-policy
statement is present, it is a configuration error for the
allow-update
statement to be present. The update-policy
statement only examines the signer of a message; the
source address is not relevant.
A sample rule definition is as shown below:
( grant | deny ) identity nametype name [ types ]
Each rule grants or denies privileges. Once a message has successfully matched a rule, the operation is
immediately granted or denied and no further rules are examined. A rule is matched when the signer
matches the identity field, the name matches the name field, and the type is specified in the list in the
types field.
The identity field specifies a name or a wildcard name. Normally, this is the name of the TSIG or SIG(0)
key used to sign the update request. When a TKEY exchange has been used to create a shared secret, the
identity of the shared secret is the same as the identity of the key used to authenticate the TKEY
exchange. When the identity field specifies a wildcard name, it is subject to DNS wildcard expansion, so
the rule will apply to multiple identities. The identity field must contain a fully qualified domain name.
The nametype field has four possible values:
name Exact-match semantics. This rule matches when the name being updated is identical to
the contents of the name field.
subdomain This rule matches when the name being updated is a subdomain of, or identical to, the
contents of the name field.
wildcard The name field is subject to DNS wildcard expansion, and this rule matches when the
name being updated is a valid expansion of the wildcard.
self This rule matches when the name being updated matches the contents of the identity
field. The name field is ignored, but should be the same as the identity field. The self
nametype is most useful when allowing the use of one key per name to update, where the
key has the same name as the name to be updated. The identity would be specified as *
in this case.
In all cases, the name field must specify a fully qualified domain name.
If no types are explicitly specified, this rule matches all types except
SIG, NS, SOA, and XT.Atype may
be specified by name, including ANY (which matches all types except NXT, which can never be updated).
Note that when an attempt is made to delete all records associated with a name, the rules are checked for
each existing record type.
The Statistics File
The statistics file generated by BIND 9.3 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 time stamp, measured as seconds since Janu-
ary 1, 1970. Following that line are a series of lines containing a counter type, the value of the counter,
HP-UX 11i Version 3: September 2010 − 29 − Hewlett-Packard Company 29