8.10 Configuring a DHCP Server to Update a BIND Name Server

8.10.1 Problem

You want to configure the ISC DHCP
server to update a BIND name server.

8.10.2 Solution

Within the dhcpd.conf
file, add a ddns-domainname statement
and a ddns-rev-domainname statement, if
necessary. These define the name of the forward-mapping zone to add A
records to and the suffix to append to inverted addresses to form the
owner names of PTR records to add, respectively. The default
ddns-rev-domainname is, naturally,
in-addr.arpa. Here's an
example:

ddns-domainname "foo.example";
ddns-rev-domainname "in-addr.arpa";

Next, add statements to specify the
update style and whether the DHCP server should allow clients to
update their own A records, if they wish. The recommended update
style is "interim", which is
described in this recipe. If you also want the DHCP server to handle
all dynamic updates, add these statements:

ddns-update-style interim;
ignore client-updates;

Then
define a TSIG key to use to sign updates. The syntax of the
key statement is nearly identical to that used
in the like-named statement in named.conf.
Here's an example key
statement:

Note that
there's no semicolon at the end of the statement
(after "}").

Finally, add
zone statements telling the DHCP server the
domain names of the zones it will update, and for each of these, the
address of the name server to send updates to and the TSIG key to
sign those updates with. For example:

In this case, the DHCP server and the primary master name server for
foo.example and
0.168.192.in-addr.arpa -- the zones the DHCP
server needs to update -- are running on the same host, so I
specified the loopback address.

On
the name server's side, use the newfangled
update-policy zone substatement to limit which
records the DHCP server's TSIG key can update. All
the DHCP server should update in foo.example are
A and TXT records, and never for the domain name of the zone. In the
0.168.192.in-addr.arpa zone, the DHCP server
should only update PTR records. These zone
statements enforce those restrictions:

8.10.3 Discussion

When
ignoring client updates, the DHCP server determines the domain name
of the DHCP client by concatenating the first label of the domain
name the client specifies in the FQDN option with the setting for the
ddns-domainname.

The
DHCP server needs to add TXT RRs to the forward-mapping zone because
they're part of a clever mechanism it uses to avoid
name collisions. When the DHCP initially adds an A record for a DHCP
client, it computes a unique hash value for that client, based on the
client's MAC address and other parameters. Then, it
adds not just the A record to the client's domain
name, but also a TXT record that contains the hash value.

Whenever the DHCP server needs to update a domain
name's A record, it sets as a prerequisite that the
domain name own a TXT record that matches the
client's calculated hash value. If a TXT records
exists with a different hash value, then another DHCP client is
already using the same domain name.

8.10.4 See Also

dhcpd.conf(5), for more information on the
syntax of dhcpd.conf and of the DHCP
server's support for dynamic update; Section 3.11, for an explanation of
update-policy.