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:
key dhcp-server.foo.example. { algorithm hmac-md5; secret "R2xOu1NWXSPkvNqfP8Rm6Q=="; }
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:
zone foo.example. { primary 127.0.0.1; key dhcp-server.foo.example.; } zone 0.168.192.in-addr.arpa. { primary 127.0.0.1; key dhcp-server.foo.example.; }
Again, there's no semicolon at the end of the statement.
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:
zone "foo.example" { type master; file "db.foo.example"; update-policy { grant dhcp-server.foo.example. wildcard *.nxdomain.com. A TXT; }; }; zone "0.168.192.in-addr.arpa" { type master; file "db.192.168.0"; update-policy { grant dhcp-server.foo.example. wildcard *.0.168.192.in-addr.arpa. PTR; }; };
For more information on update-policy, see Section 3.11.
8.10.3 Discussion
The 3.0 version of the ISC DHCP server supports sending dynamic updates. You can get a copy from http://www.isc.org/products/DHCP/.
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.