DDNS and Update Failure

[Kevin Darcy]

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.
>
>  
>