DDNS and Update Failure

[Scott Dudley]

Thanks Kevin.  I posted this message previously to the DHCP forum and 
Ted basically told me that he had bigger fish to fry - no other 
respondents.  Thanks anyway.  Guess I'll have to roll up my sleeves and 
figure this one out on my own.  I'm an applications developer, not a 
sysadmin and hoped to not have to learn either application to this extent.

Thanks.

Kevin Darcy wrote:

>Well, it's odd that this only started happening after your BIND upgrade, 
>but the truth is, BIND doesn't know anything about MAC addresses, and as 
>far as Dynamic Update is concerned, it does only what it's told to by 
>the DHCP server making the update. The immediate problem, as you can see 
>from the logs, is that the DHCP server is putting in some prerequisites 
>for its updates, and since those prerequisites aren't being met, the 
>updates are being rejected. This seems to be working exactly as 
>intended. Prerequisites were spelled out quite clearly and unambiguously 
>in RFC 2136 and as far as I know, didn't change between BIND 8 and BIND 
>9. If it did change, it is far more likely that the new behavior 
>conforms to the standard much better than the old version, since 
>standards-conformance was one of the main reasons BIND 9 was written 
>from scratch to supercede BIND 8. I suppose it's possible that your 
>dhcpd was relying on some sort of buggy behavior in BIND 8's 
>prerequisite handling, and now that buggy behavior has gone away (????). 
>If you really want to ensure you're pointing the finger of blame at the 
>right piece of software, you'd probably have to run a sniffer trace to 
>see which software is at fault.
>
>I'd suggest looking at the dhcpd documentation, or asking on a dhcpd 
>mailing list or newsgroup, whether there is some sort of configuration 
>option to prevent this from happening with respect to a BIND 9 nameserver.
>
>- Kevin
>
>Scott Dudley wrote:
>
>  
>
>>I setup an older version of BIND 8 and ISC's dhcpd on a RedHat 7.2 
>>system several years ago. This system is on a small and isolated LAN 
>>used by our hardware department to test returned systems. They recently 
>>upgraded the system to RedHat 9 (bind-9.2.1-16) at which time DDNS 
>>stopped working. DHCP is version 3.0.1rc13 and didn't change. Their
>>
>>test bed environment is setup such that they have numbers assigned to each position and they name each PC placed on the test bed accordingly (i.e. pc1, pc2, etc.).  I have some CGI's that run on the server and access these pcs by name.  Looks to me like there's now some constraint imposed that precludes a machine with a new MAC from laying claim to the 
>>same name.  How do I fix this?  I can see how this would be important in an environment other than ours but in this case, my previously working test environment no longer functional.
>>
>>Here's syslog output:
>>
>>Jul 23 14:23:57 dosxx dhcpd: DHCPDISCOVER from 00:60:e0:81:86:b1 via eth1
>>Jul 23 14:23:58 dosxx dhcpd: DHCPOFFER on 192.168.0.174 to 00:60:e0:81:86:b1 (pc13) via eth1
>>Jul 23 14:23:58 dosxx named[4435]: client 192.168.0.1#32779: updating zone 'testbed.net/IN': update failed: 'name not in use' prerequisite not satisfied (YXDOMAIN)
>>Jul 23 14:23:58 dosxx named[4435]: client 192.168.0.1#32779: updating zone 'testbed.net/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
>>Jul 23 14:23:58 dosxx dhcpd: Can't update forward map pc13.testbed.net to 192.168.0.174: no such RRsetJul 23 14:23:58 dosxx dhcpd: DHCPREQUEST for 192.168.0.174 (192.168.0.1) from 00:60:e0:81:86:b1 (pc13) via eth1
>>Jul 23 14:23:58 dosxx dhcpd: DHCPACK on 192.168.0.174 to 00:60:e0:81:86:b1 (pc13) via eth1
>>
>>Many thanks.
>>
>> 
>>
>>    
>>
>
>
>
>  
>

-- 

Regards,

Scott Dudley