3.12 Configuring a Name Server to Forward Dynamic Updates

3.12.1 Problem

You want a BIND 9 slave name server to forward any dynamic updates it receives from addresses on the local networks for a zone to its master name server.

3.12.2 Solution

Use the allow-update-forwarding zone substatement. For example:

zone "foo.example" {
    type slave;
    masters { 192.168.0.1; };
    file "bak.foo.example";
    allow-update-forwarding { localnets; };
};

The slave name server forwards any dynamic updates it receives to the foo.example zone to its master name server, at 192.168.0.1.

3.12.3 Discussion

For the most part, if you make sure that your zone's SOA record contains the domain name of the primary master name server in the MNAME field, you won't need to worry about update forwarding. Most updaters will automatically find your primary master and send their updates there. But if you use a hidden primary master or have ill-behaved clients, you may need this.

Forwarding updates, however, makes IP address-based authorization using allow-update even more dangerous than usual, because forwarded updates have the slave name server's source address. If you use update forwarding, you should use TSIG-signed dynamic updates, too. It doesn't matter if a slave forwards a signed update: it still bears the signature.

3.12.4 See Also

Section 3.11 for permitting dynamic updates; Recipes Section 5.20, Section 5.21, and Section 5.23 for sending dynamic updates -- particularly TSIG-signed updates -- using nsupdate; Recipes Section 9.10 and Section 9.11 for sending updates programmatically; and "TSIG-Signed Updates" in Chapter 10 of DNS and BIND.