deleting releases after failing to delete a DDNS entry

[Ralf Goertz]

Hi,

I use dhcpd 3.0.5 and bind 9.3.2 with DDNS. Everthing works fine except
that every once in a while after shutting down a client machine (e.g.
"dms.site") it's DDNS record deletion times out:

> Jun  3 19:15:02 server named[25555]: client 192.168.xxx.254#1142:
> updating zone 'site/IN': deleting an RR

> Jun  3 19:15:03 server dhcpd: if dms.site IN TXT "[deleted]" rrset
> exists and dms.site IN A 192.168.xxx.219 rrset exists delete dms.site
> IN A 192.168.xxx.219: timed out.

Somehow the communication between dhcpd and named was disturbed, I don't
know the reason for that since both are running on the same server and
five minutes later (without any intervention) the deletion of some other
client's records succeeds.

The next morning when dms.site is booted up the user on it can't use his
nfs-based home directory because the nfs-server (which is also running
on the same server machine) says:

> Jun  4 08:46:33 server mountd[3821]: Fake hostname dms.site for
> 192.168.xxx.219 - forward lookup doesn't exist

Then I have to manually stop dhcpd, delete the "dms.site" entries from
dhcp.leases and restart dhcpd. After that everything works fine again.

I understand that dhcpd does not delete the "dms.site" record since it
(erroneously) believes that the deletion of the DDNS forward record
failed. As far as I see it doesn't even try to delete the reverse
record. Then it does not try to add new DDNS records the next morning
and we are left with only a reverse entry which makes the nfs-server
choke.

What can I do make dhcpd delete the leases even if the DDNS-record
deletion fails?

Thanks,

Ralf