unsuccessful update of A record

[Ross Boylan]

While working on some network problems I rebooted a dhcp client system
several times.  For some reason, one of those times the client got a
new IP address from the dhcpd server.  My forward (A) DNS ended up
pointing at the old location, and the bind logs show the update to the
A record failed because there was an existing entry for that name.

The logs also show that before updating the reverse record the old
entry is deleted.

In previous discussion on this list, someone mentioned a proposed
standard that involved not updating records that already exist (I
think just the forward ones), so this behavior is consistent with
that.

Why are the forward records left in place while the reverse records
are deleted before update?  Is this part of the asymmetry noted a few
weeks ago, in which the DHCP server is deemed more authoritative about
the IP addresses than the names?

Second, should the client, when shutdown normally, tell the server
that it is going down, so the dhcp server could make appropriate
adjustments--including deleting DNS entries?  The DNS entries only get
cleared out for me when the lease expires.  The dhcpd.conf man page in
REFERENCE: EVENTS refers explicitly to a "release event, when the
client has released the server from its commitment."

Is there a way to get the DNS records deleted when the client goes
down and, failing that, to get old information replaced with new
information?  It would be easier if this could be done once on the
server, particularly since some of my clients are MS Windows some of
the time.

My leases are relatively brief, so at least the problems tend to
self-correct after a few hours.