force DDNS update

Carl Karsten carl at personnelware.com
Mon Apr 23 17:21:45 UTC 2007


Simon Hobson wrote:
> Jason Gerdes wrote:
> 
>> I have been lurking here for a while with a similar issue.  I have 
>> some 'stale' or nonexistent ddns records with the same setup.  Is 
>> there a way to clear out all of the old mappings and just start 
>> fresh, so to speak.  I have some network scripts that rely on the 
>> hostname to be correct and this problem is wreaking havok on those 
>> processes.  I have been receiving this error message in my logs that 
>> I think might possibly help with the diagnosis:
>>
>> update failed: 'name not in use' prerequisite not satisfied (YXDOMAIN)
> 
> Yes, simply delete the stale records using nsupdate*

That just dumps the 'incorrect' entry, but won't add the correct one, right? 
guessing the easiest way to fix is force the client to do another dchp request?

Is there some way to get dhcpd to do this?

> 
> Thw DHCP server will NOT replace or remove an A record that does not 
> have the correct TXT record to go with it. The TXT record has a hash 
> of several bits of information that allows the server to determine 
> that it wasn't something else that put the record there. This is a 
> safety feature - otherwise someone could name their client "server" 
> and the DHCP server would happily replace the A record for you 
> important server of the same name with one that points to the client, 
> with the obvious effects on the network !

I see your point.  But I think we can get the best of both worlds.

In my case, dhcpd is the only thing with the key.

The host name comes from the following:

Client supplied

host sahara {
         hardware ethernet 00:40:ca:11:3c:6c ;
         option host-name "sahara" ;
         fixed-address 192.168.1.3 ; }

option host-name=concat("dhcp", binary-to-ascii(10, 8, "-", 
suffix(leased-address,1) ) ) ;

What determines the precedence order,
and is there a way to ignore the client supplied one?

> The TXT record has a hash 
> of several bits of information that allows the server to determine 
> that it wasn't something else that put the record there.

Which server? (dhcp or bind?)

This has me wondering:
Box1 does DHCPREQUEST and gets a lease.
Could a Box2 construct a DHCPRELEASE that looks like it came from Box1 so that 
the dhcp server doesn't know that Box1 is still using the IP?

Carl K


More information about the dhcp-users mailing list