Allowing Dynamic Updates

3.11.1 Problem

You want to allow dynamic updates to one of your zones.

3.11.2 Solution

Use the allow-update zone substatement. For example:

zone "foo.example" { type master; file "db.foo.example"; allow-update { 192.168.0.4; }; };

This allows dynamic updates to the foo.example zone from the IP address 192.168.0.4. You can specify multiple addresses, or a whole range of addresses, but that's generally a bad idea: You want to restrict dynamic updates as much as possible, since an updater allowed via allow-update can make just about any change to the zone.

In fact, if you run a BIND 9 name server and the software sending dynamic updates supports TSIG-signed updates, you should use the new update-policy substatement. update-policy lets you determine which domain names and records a particular updater is allowed to update. update-policy substatements have the following format:

update-policy { grant|deny keyname nametype domain-name [type [...]]; [...] };

The keyname field is the name of the TSIG key used to sign the dynamic update. The nametype is one of these four values:

name

Matches when the updated domain name is the same as the name in the domain-name field.

subdomain

Matches when the updated domain name is a subdomain (that is, ends in or is the same as) the name in the domain-name field.

wildcard

Matches when the updated domain name matches the wildcard expression in the domain-name field. Only the leftmost label in the expression can be a wildcard character.

self

Matches when the updated domain name is the same as the name of the TSIG key that signed the update. The contents of the domain-name field are ignored, but the field needs to be present.

The type is a record type, such as A, MX, and NS. You can use ANY as shorthand for all record types except NXT. If you omit the field, the default is to allow updates to all types except SOA, NS, SIG, and NXT.

So, for example, in order to restrict dynamic updates to A records for the domain name www.foo.example to updates signed with the key update-key, you could use this update-policy substatement:

zone "foo.example" { type master; file "db.foo.example"; update-policy { grant update-key name www.foo.example A; }; };

3.11.3 Discussion

allow-update really isn't secure, since it authorizes updates on the basis of the source IP address in the dynamic update message. And dynamic updates are UDP-based, so they're easy to spoof. Unfortunately, there's very little software that supports TSIG-signed dynamic updates -- yet.

If you allow dynamic updates to a zone, make sure the MNAME field of the zone's SOA record contains the domain name of the primary master name server; ideally, that's where updaters will send their updates.

The allow-update and update-policy substatements are only meaningful in zone statements of type master, since you can only modify data on a zone's primary master name server.

3.11.4 See Also

Recipes Section 3.20 and Section 3.21, for information on how to send dynamic updates using nsupdate; Section 5.23, for sending TSIG-signed updates using nsupdate; Recipe 8.9, for a more complex example of update-policy; Recipes Section 9.10 and Section 9.11, to learn how to send updates programmatically; and "DNS Dynamic Update" in Chapter 10 of DNS and BIND.