BIND update-policy option

The update-policy statement applies to zone statements for type primary only. It allows specification of granular permissions for performing dynamic updates for given update originators. Such an originator is identified as the signer of the update. The identity field of the update-policy statement is matched against the identity of the signer of the message (keyname of the associated TSIG record or signer of associated SIG(0) record) and the update itself is compared with the nametype, name and types fields. If a match is found, the rule (grant or deny) is applied. Alternatively, a pre-defined local policy may be defined. The rule specification as of BIND 9.20 consists of the following fields:

• local - a pre-defined policy setting which causes named to automatically create a TSIG key and sign updates performed locally on the server, e.g., via nsupdate -l.
• ( grant | deny ) - grants or denies the matching specified update from the signer
• identity - identity of the signer of the update or a wildcard, which must be in the format of a fully qualified domain name
• ruletype - defines the matching criteria for the given update attempt. One of the following values may be specified:
  • name - the name being updated must exactly match the update-policy name field
  • subdomain - the name being updated must exactly match or be a subdomain of the update-policy name field.
  • zonesub - equivalent to the subdomain nametype except that it obviates the need to specify the name field; hence it applies to matches to this zone in which it is configured and its subdomains. This enables specification of a common update-policy statement with this zonesub ruletype in multiple zone files.
  • wildcard - the name being updated must be a valid wildcard expansion of the update-policy name field.
  • self - the name being updated must exactly match the update-policy identity field
  • selfsub - the name being updated must exactly match or be a subdomain of the update-policy identity field
  • selfwild - the name being updated must be a subdomain of the update-policy identity field
  • ms-self - When a client sends an UPDATE using a Windows machine principal (for example, machine$@REALM), this rule allows any machine in the specified realm to update any record in the zone or in a specified subdomain of the zone, where the realm is matched to the identity field. The name field specifies the subdomain that may be updated. If set to “.” or any other name at or above the zone apex, any name in the zone can be updated.
  • ms-subdomain - When a client sends an UPDATE using a Windows machine principal (for example, machine$@REALM), this rule allows records with the absolute name of machine.REALM to be updated, where the realm is matched to the identity field. The name field has no effect for this rule and should be set to ".".
  • ms-subdomain-self-rhs - This rule is similar to the ms-subdomain rule, with the additional restriction that PTR and SRV target names must match the name fo the machine identified in the principal.
  • krb5-self - When a client sends an UPDATE using a Kerberos machine principal (for example, host/machine@REALM), this rule allows records with the absolute name of machine to be updated, provided it has been authenticated by REALM. This is similar but not identical to ms-self, due to the machine part of the Kerberos principal being an absolute name instead of an unqualified name. The realm is matched to the identity field. The name field has no effect for this rule and should be set to ".".
  • krb5-selfsub - This rule is similar to the krb5-self rule, except it also allows updates to any subdomain of the name specified in the machine part of the Kerberos principal, not just to the name itself.
  • krb5-subdomain - This rule is identical to ms-subdomain, except that it works with Kerberos machine principals (i.e., host/machine@REALM) rather than Windows machine principals.
  • krb5-subdomain-self-rhs -This rule is similar to krb5-subdomain, with an additional restriction that PTR and SRV target names must match the name of the machine identified in the principal
  • tcp-self - allow updates sent via TCP for which the updater's source IP address maps into a corresponding in-addr.arpa or ip6.arpa domain [subtree] being updated.
  • 6to4self - allow updates to the 6to4 prefix by a TCP connection from the 6to4 network or corresponding IPv4 address mapped into the 6to4 address (intended to allow NS or DNAME RR updates)
  • external - enables the server to rely on an external daemon to grant or deny the update attempt.
• name - fully qualified domain name corresponding to the attempted update
• types - (optional) resource record types for which the rule applies. All types may be specified except NS, NSEC, RRSIG and SOA. Type ANY (the default) may be specified to match all types except NSEC, which cannot be updated.

Consider this example:

This statement allows any host within ipamworlwide.com to update its own record (self-signed) while denying holders of the oldkey.ipamworlwide.com. key from updating A records for ad.ipamworldwide and its subdomains.