unsuccessful update of A record

Tue Apr 4 00:12:39 UTC 2006

On Mon, Apr 03, 2006 at 09:28:04AM +0000, Simon Hobson wrote:
> Ross Boylan wrote:
> 
> >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.
> 
> Can you post the log entries.
These are from bind9 logging category update.

31-Mar-2006 15:33:13.178 update: info: client 127.0.0.1#36659: view inside: updating zone 'betterworld.us/IN': adding an RR at 'corn.betterworld.us' A
31-Mar-2006 15:33:13.284 update: info: client 127.0.0.1#36659: view inside: updating zone 'betterworld.us/IN': adding an RR at 'corn.betterworld.us' TXT
31-Mar-2006 15:33:13.413 update: info: client 127.0.0.1#36659: view inside: updating zone '192.in-addr.arpa/IN': deleting rrset at '25.40.168.192.in-addr.arpa' PTR
31-Mar-2006 15:33:13.414 update: info: client 127.0.0.1#36659: view inside: updating zone '192.in-addr.arpa/IN': adding an RR at '25.40.168.192.in-addr.arpa' PTR
31-Mar-2006 16:00:25.004 update: info: client 127.0.0.1#36659: view inside: updating zone 'betterworld.us/IN': update unsuccessful: corn.betterworld.us: 'name not in use' prerequisite not satisfied (YXDOMAIN)
31-Mar-2006 16:00:25.006 update: info: client 127.0.0.1#36659: view inside: updating zone 'betterworld.us/IN': update unsuccessful: corn.betterworld.us/TXT: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
31-Mar-2006 16:28:23.011 update: info: client 127.0.0.1#36659: view inside: updating zone 'betterworld.us/IN': update unsuccessful: corn.betterworld.us: 'name not in use' prerequisite not satisfied (YXDOMAIN)
31-Mar-2006 16:28:23.029 update: info: client 127.0.0.1#36659: view inside: updating zone 'betterworld.us/IN': update unsuccessful: corn.betterworld.us/TXT: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
# It tried several more times thereafter
19:46
22:27
then
31-Mar-2006 22:34:13.020 update: info: client 127.0.0.1#36669: view inside: updating zone 'betterworld.us/IN': deleting an RR
31-Mar-2006 22:34:13.219 update: info: client 127.0.0.1#36669: view inside: updating zone 'betterworld.us/IN': deleting an RR
31-Mar-2006 22:34:13.240 update: info: client 127.0.0.1#36669: view inside: updating zone '192.in-addr.arpa/IN': deleting rrset at '25.40.168.192.in-addr.arpa' PTR
01-Apr-2006 09:26:03.225 update: info: client 127.0.0.1#36687: view inside: updating zone 'betterworld.us/IN': adding an RR at 'corn.betterworld.us' A
01-Apr-2006 09:26:03.287 update: info: client 127.0.0.1#36687: view inside: updating zone 'betterworld.us/IN': adding an RR at 'corn.betterworld.us' TXT
01-Apr-2006 09:26:03.402 update: info: client 127.0.0.1#36687: view inside: updating zone '192.in-addr.arpa/IN': deleting rrset at '45.40.168.192.in-addr.arpa' PTR
01-Apr-2006 09:26:03.402 update: info: client 127.0.0.1#36687: view inside: updating zone '192.in-addr.arpa/IN': adding an RR at '45.40.168.192.in-addr.arpa' PTR

So I guess it keeps trying to update DNS until it succeeds?  And the
deletions above represent the expiry of the old lease?

Or did you mean some other entries (e.g., to try to figure  out why I
didn't get the same IP address--oh, I think I see.  The client came
back up and asked for its old IP address.  But the server decided the
address was in use, since there was an active lease.  So it gave out a
different one.  Right?)
> 
> >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.
> 
> That is correct, the standard functionality is that the server will 
> not replace an active entry
> 
> >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?
> 
> That is up to the client. Mac OS X clients do that, they explicitly 
> release their lease before shutting down, most clients don't. There 

Is this configurable with the dchp3 client?

> are pros and cons both ways : releasing the lease virtually 
> eliminates the problems caused by moving subnets when the dhcp server 
> is not authoritative; on the other hand, hanging on to it makes the 
> client more robust (it generally has a working address when it starts 
> so less problems if the dhcp server dies or there's a temporary 
> network problem).

Is it the case that the client will try to get its old IP even if it
has given up the lease?  I was mostly thinking of that, but I see your
point about dealing with outages.

> 
> >   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."
> 
> If the client releases the lease, then the dhcp server will delete 
> the dns entries, if not then they will remain until the lease expires.
> 
> >Is there a way to get the DNS records deleted when the client goes
> >down
> 
> Only if the client releases the lease - otherwise, the server has no 
> way of knowing if the client is really gone or if it's going to pop 
> back up and carry on using the address (which it is entitled to do 
> until the lease expires).
> 
> >  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.
> 
> Can you come up with a reliable and SAFE methond for deciding what 
> dns entries it's safe to replace, and which need to stay ?

I can come up with a method that is reliable enough for me, but I'd
guess from the lack of this feature, and the discussion here of client
id's, that there isn't a way that's reliable in general.  There are
all kinds of oddball scenarios even I can come up with (switching
ethernet cards between machines, two clients with same hostname, ...).

But let me turn that around: if the server is about to hand out an IP
address to a machine that already has a forward record with a
different IP address, isn't that a sign that something is wrong?  Even
so, I guess the proper behavior isn't clear, particularly since dhcp
clients may not be setup for passing on warning messages.

Anyway, it would be nice to have some hooks for alternate ways of
dealing with this.  Maybe they are there, and I just don't know them.

> 
> >My leases are relatively brief, so at least the problems tend to
> >self-correct after a few hours.
> 
> They can be manually corrected. Use nsupdate to delete the old 
> records and then get the client to renew it's lease. For completeness 
> you also need to stop the dhcp server and remove the ddns-update 
> entries in the old lease record.

Thanks; I hadn't thought of the lease record.
To be honest, I've never used nsupdate, and am a little intimidated by
having to figure out how to provide appropriate credentials.  I'm sure
it's not a big deal, but just big enough to stop me :)

> 
> Better still, if you knwo that you are modifying the client, manually 
> release it's lease beforehand (on Windows it's "ifconfig /release").

Is there a linux analogue?

> 
> Simon
> 
> 
Thanks.
Ross