How to allow dynamic updates with BIND

If you want to allow dynamic updates to one of your zones, 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:

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;

    };

};

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.