diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml
index 835466269dda74bab8bd157653a23f0c141f2513..c876fe35371d09f504cf7774b0212659186f3ee8 100644
--- a/doc/arm/Bv9ARM-book.xml
+++ b/doc/arm/Bv9ARM-book.xml
@@ -12441,69 +12441,68 @@ example.com. NS ns2.example.net.
update-policy option, 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 allow-update clause is a simple
+ access control list. Any client that matches
+ the ACL is granted permission to update any record
+ in the zone.
The update-policy clause
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.
+ allowed. It specifies a set of rules, in which each rule
+ either grants or denies permission for one or more
+ names in the zone to be updated by one or more
+ identities. Identity is determined by the key that
+ signed the update request using either TSIG or SIG(0).
+ In most cases, update-policy rules
+ only apply to key-based identities. There is no way
+ to specify update permissions based on client source
+ address.
- 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
- (except when set to local) only
- examines the signer of a message; the source
- address is not relevant.
+ update-policy rules are only meaningful
+ for zones of type master, and are
+ not allowed in any other zone type.
+ It is a configuration error to specify both
+ allow-update and
+ update-policy at the same time.
A pre-defined update-policy rule can be
switched on with the command
update-policy local;.
- Switching on this rule in a zone causes
- named to generate a TSIG session key and
- place it in a file. That key will then be allowed to update
- the zone, if the update request is sent from localhost.
+ Using this in a zone causes
+ named to generate a TSIG session key
+ when starting up and store it in a file; this key can then
+ be used by local clients to update the zone while
+ named is running.
By default, the session key is stored in the file
- /var/run/named/session.key; the key name
- is "local-ddns" and the key algorithm is HMAC-SHA256.
+ /var/run/named/session.key, the key name
+ is "local-ddns", and the key algorithm is HMAC-SHA256.
These values are configurable with the
session-keyfile,
session-keyname and
- session-keyalg options, respectively).
-
-
- A client on the local system, if it is run with appropriate
+ session-keyalg options, respectively.
+ A client running on the local system, if run with appropriate
permissions, may read the session key from the key file and
- use the key to sign update requests. The zone's update
+ use it to sign update requests. The zone's update
policy will be set to allow that key to change any record
within the zone. Assuming the key name is "local-ddns",
- this policy is:
+ this policy is equivalent to:
update-policy { grant local-ddns zonesub any; };
- ...with an additional restriction that only clients
+ ...with the additional restriction that only clients
connecting from the local system will be permitted to send
updates.
- Note that only one session key is generated; all zones
- configured to use update-policy local
- will accept the same key.
+ Note that only one session key is generated by
+ named; all zones configured to use
+ update-policy local will accept the same key.
The command nsupdate -l implements this
@@ -12516,50 +12515,60 @@ example.com. NS ns2.example.net.
-( grant | deny ) identity nametype name types
+( grant | deny ) identity ruletype 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 in accordance with the nametype
- field, and the type matches the types specified in the type
- field.
+ Each rule grants or denies privileges. Rules are checked
+ in the order in which they are specified in the
+ update-policy statement. Once a message
+ has successfully matched a rule, the operation is immediately
+ granted or denied, and no further rules are examined. There
+ are 13 types of rules; the rule type is specified by the
+ ruletype field, and the interpretation
+ of other fields varies depending on the rule type.
+
+
+ In general, a rule is matched when the
+ key that signed an update request matches the
+ identity field, the name of the record
+ to be updated matches the name field
+ (in the manner specified by the ruletype
+ field), and the type of the record to be updated matches the
+ types field. Details for each rule type
+ are described below.
- No signer is required for tcp-self
- or 6to4-self however the standard
- reverse mapping / prefix conversion must match the identity
- field.
+ The identity field must be set to
+ a fully-qualified domain name. In most cases, this
+ represensts the name of the TSIG or SIG(0) key that must be
+ used to sign the update request. If the specified name is a
+ wildcard, it is subject to DNS wildcard expansion, and the
+ rule may apply to multiple identities. When a TKEY exchange
+ has been used to create a shared secret, the identity of
+ the key used to authenticate the TKEY exchange will be
+ used as the identity of the shared secret. Some rule types
+ use indentities matching the client's Kerberos principal
+ (e.g, "host/machine@REALM") or
+ Windows realm (machine$@REALM).
- 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. TKEY is also the negotiation method used
- by GSS-TSIG, which establishes an identity that is
- the Kerberos principal of the client, such as
- "user@host.domain". 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 name field also specifies
+ a fully-qualified domain name. This often
+ represents the name of the record to be updated.
+ Interpretation of this field is dependent on rule type.
- For nametypes krb5-self,
- ms-self, krb5-subdomain,
- and ms-subdomain the
- identity field specifies
- the Windows or Kerberos realm of the machine belongs to.
+ If no types are explicitly specified,
+ then a rule matches all types except RRSIG, NS, SOA, NSEC
+ and NSEC3. Types may be specified by name, including
+ "ANY" (ANY matches all types except NSEC and NSEC3,
+ 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 nametype field has 13
+ The ruletype field has 13
values:
name, subdomain,
wildcard, self,
@@ -12647,20 +12656,23 @@ example.com. NS ns2.example.net.
- This rule matches when the name being updated
- matches the contents of the
+ This rule matches when the name of the record
+ being updated matches the contents of the
identity field.
The name field
- is ignored, but should be the same as the
- identity field or
+ is ignored. To avoid confusion, it is recommended
+ that this field be set to the same value as the
+ identity field or to
"."
- The self nametype is
- most useful when allowing using one key per
+
+
+ The self rule type is
+ most useful when allowing 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 * (an asterisk) in
- this case.
+ name as the record to be updated. In this case,
+ the identity field
+ can be specified as *
+ (an asterisk).
@@ -12762,11 +12774,18 @@ example.com. NS ns2.example.net.
- Allow updates that have been sent via TCP and
- for which the standard mapping from the initiating
- IP address into the IN-ADDR.ARPA and IP6.ARPA
- namespaces match the name to be updated. The
- name field should be set to "."
+ This rule allows updates that have been sent via
+ TCP and for which the standard mapping from the
+ client's IP address into the
+ in-addr.arpa and
+ ip6.arpa
+ namespaces match the name to be updated.
+ The identity field must match
+ that name. The name field
+ should be set to ".".
+ Note that, since identity is based on the client's
+ IP address, it is not necessary for update request
+ messages to be signed.
It is theoretically possible to spoof these TCP
@@ -12781,11 +12800,30 @@ example.com. NS ns2.example.net.
- Allow the 6to4 prefix to be update by any TCP
- connection from the 6to4 network or from the
- corresponding IPv4 address. This is intended
- to allow NS or DNAME RRsets to be added to the
- reverse tree.
+ This allows the name matching a 6to4 IPv6 prefix,
+ as specified in RFC 3056, to be updated by any
+ TCP connection from either the 6to4 network or
+ from the corresponding IPv4 address. This is
+ intended to allow NS or DNAME RRsets to be added
+ to the ip6.arpa reverse tree.
+
+
+ The identity field must match
+ the 6to4 prefix in ip6.arpa.
+ The name field should
+ be set to ".".
+ Note that, since identity is based on the client's
+ IP address, it is not necessary for update request
+ messages to be signed.
+
+
+ In addition, if specified for an
+ ip6.arpa name outside of the
+ 2.0.0.2.ip6.arpa namespace,
+ the corresponding /48 reverse name can be updated.
+ For example, TCP/IPv6 connections
+ from 2001:DB8:ED0C::/48 can update records at
+ C.0.D.E.8.B.D.0.1.0.0.2.ip6.arpa.
It is theoretically possible to spoof these TCP
@@ -12839,21 +12877,6 @@ example.com. NS ns2.example.net.
-
-
- 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 RRSIG, NS, SOA, NSEC and NSEC3. Types
- may be specified by name, including "ANY" (ANY matches
- all types except NSEC and NSEC3, 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.
-