A little while after setting up DNS and a
DHCP server for my local network, I noticed dhcpd
error
messages as shown below:
crimson dhcpd: Can't update forward map opal.hydrus.org.uk to 192.168.0.39: no such RRset crimson dhcpd: if opal.hydrus.org.uk IN TXT "0018afbf6c32d85b1f1ccbef262e16ef4c" rrset exists and opal.hydrus.org.uk IN A 192.168.0.40 rrset exists delete opal.hydrus.org.uk IN A 192.168.0.40: no such RRset.
The consequence of this was that an incorrect IP address existed for opal in the DNS.
The messages only occurred for machines that dual-booted with Windows
(opal runs Windows XP as well as FreeBSD). I investigated the
/var/db/dhcpd/dhcpd.leases
file, which is where dhcpd keeps
the IPs it has assigned to DHCP clients. Here's the lease for a
Windows client:
lease 192.168.0.45 { starts 0 2006/04/02 15:35:16; ends 0 2006/04/02 17:35:16; binding state active; next binding state free; hardware ethernet 00:09:5b:54:1f:bb; uid "\001\000\011[T\037\273"; set ddns-rev-name = "45.0.168.192.in-addr.arpa."; set ddns-txt = "31caf5f7d17b445e52b920285dcf4457d3"; set ddns-fwd-name = "maroon.hydrus.org.uk"; client-hostname "maroon"; }
And here's the lease for a non-Windows client:
lease 192.168.0.41 { starts 0 2006/04/02 16:08:00; ends 0 2006/04/02 18:08:00; binding state active; next binding state free; hardware ethernet 00:40:f4:1a:22:bd; set ddns-rev-name = "41.0.168.192.in-addr.arpa."; set ddns-txt = "31975f395f58847f2aa8f28c2969a05511"; set ddns-fwd-name = "gold.hydrus.org.uk"; client-hostname "gold"; }
A quick glance will show that Windows leases have a uid
element,
whereas non-Windows leases do not. The uid
is the ethernet
address of the client, preceeded by a "1" (for ethernet). I
surmised that both the hardware ethernet address and the uid (if
present) were used to identify a client machine in the Resource
Record set (RRset) in DNS. So, I had to make the non-Windows
clients emulate the Windows behaviour and all should be well.
This is very simple to achieve: add the line:
send dhcp-client-identifier 1:00:40:f4:1a:22:bd;
to the /etc/dhclient.conf
file. Now that both operating
systems are sending the same information to the DHCP server, the
dhcpd
error messages stopped.