division of responsibility client/dhcp/bind

Boylan, Ross Ross.Boylan at ucsf.edu
Sat Jul 25 07:15:35 UTC 2020


I have a small private network with machines that go on and off. Some of those machines may come up with the same hardware/mac address, and yet be running different OS's. The different OS's have different host names, and I would like that reflected in DNS.  An additional complication is that some of the system netboot into an NFS root.  I'm having trouble getting things to work, and think I'm missing something basic about how this is all supposed to work together.

Using ISD dhcpd 4.1, bind 9.11.5 with Debian buster.  Initial testing used an NFS root client that PXE booted (using dhcpd's support for that).

I don't understand why the DDNS update responsibility is potentially split between the server and the client.  It seems the default is that the client updates the A record while the dhcp server requests the update of the PTR record for reverse DNS.  This seems like a recipe for trouble.  First, they could get out of sync.  Second, if a key is required for updates, as was true in my initial configuration, the clients won't ordinarily have it, and so the update will fail.  Because of the second concern, I set dhcpd.conf to "ignore client-updates;".  But my reading of the manual is that this means the client's notion of its hostname will be ignored, defeating the ultimate goal of allowing different hostnames for same MAC.

Another problem was that because of the NFS boot the usual code to bring up the  interface was skipped.  So the client system didn't run dhclient.  As a result, I got DDNS entries when the client started.  But when the lease expired without further expression of interest from the client, dhcpd (successfully) requested deletion of the DNS records for the client.

Also, since dhcpd only handed out parameters during the PXE boot, many of the parameters like the domain and search list, didn't make it to the main system once it was booted.

I tried forcing the interface up on the client (specifying auto in /etc/network/interfaces).  This solved some problems while introducing others: the NIC ended up with 2 IP addresses.  Initially only the first was in DNS.  When its lease expired, there were no entries in DNS, but since dhclient was running for the 2nd IP, its lease was renewed and entered into DNS at that time.  In principle it seemed the first IP address could be handed out to another machine, and then 2 machines that would think they had the same IP.  It may be that the discovery process would suffice to prevent this, but at any rate it didn't seem to be a good state of affairs that the client thought it had an IP address that both DHCP and BIND thought was free.  Finally, the client was unable to shutdown without a manual power off because it was waiting for a response on one of the IP's "after" it shutdown.

In all the above I was assigning the client IPs from a pool, although the client had a host declaration (with the MAC but without an IP).  Some discussion on this list says  host declarations should use fixed IPs outside of the pool range.  So I gave the host declaration in dhcpd.conf a fixed IP outside the pool range, as well as a very long lease.  I also changed to the default "allow client-updates" while changing bind to accept update  without a key.

The client came up, but no dynamic DNS entries were requested or created as a result.  So does that only happen for IP's allocated out of the pool?  And  lease time is irrelevant for an IP not in the pool?

For now, I manually entered the forward and reverse DNS entries into my local zone in bind.

These last choices (dhcpd.conf gets host with fixed ip; bind gets corresponding forward and reverse entries; client does not try to bring interface up after nfs boot) mostly work.  The fact that the entries exist even when the system is down doesn't seem like much of a practical problem, but this obviously can not satisfy my original desire to allow different hostnames/OS's for the same machine and MAC.

Suggestions?

Thanks.
Ross Boylan


More information about the dhcp-users mailing list