DDNS and Update Failure

[laura.l.herndon at accenture.com]

Scott,
We had a similar issue where DDNS updates appeared in cache for
approximately a minute, then disappeared.  We were seeing the same
errors you are here.  Turned out that a system was 24 hours off and
resetting the clock resolved the issue.

My understanding is that when DHCP creates the DDNS update, it sends two
packets, one that's processed into cache immediately and one that is
slated for the updates to file.  When it's 'munged' into the file, the
one in cache is removed as being incorrect and that one is denied
because the prerequisite is not met (never did find out the reason for
the prereq, which was that 192.46.0.1 exist (regardless of address
assigned)).

Laura



Date: Wed, 11 Aug 2004 17:53:50 -0700
From: Scott Dudley <scott at telesoft.com>
Subject: Re: DDNS and Update Failure


Thanks Kevin.  I posted this message previously to the DHCP forum and=20
Ted basically told me that he had bigger fish to fry - no other=20
respondents.  Thanks anyway.  Guess I'll have to roll up my sleeves and=20
figure this one out on my own.  I'm an applications developer, not a=20
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,=20
>but the truth is, BIND doesn't know anything about MAC addresses, and
as=20
>far as Dynamic Update is concerned, it does only what it's told to by=20
>the DHCP server making the update. The immediate problem, as you can
see=20
>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=20
>updates are being rejected. This seems to be working exactly as=20
>intended. Prerequisites were spelled out quite clearly and
unambiguously=20
>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=20
>conforms to the standard much better than the old version, since=20
>standards-conformance was one of the main reasons BIND 9 was written=20
>from scratch to supercede BIND 8. I suppose it's possible that your=20
>dhcpd was relying on some sort of buggy behavior in BIND 8's=20
>prerequisite handling, and now that buggy behavior has gone away
(????).=20
>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=20
>see which software is at fault.
>
>I'd suggest looking at the dhcpd documentation, or asking on a dhcpd=20
>mailing list or newsgroup, whether there is some sort of configuration=20
>option to prevent this from happening with respect to a BIND 9
nameserver.
>
>- Kevin
>
>Scott Dudley wrote:
>
> =20
>
>>I setup an older version of BIND 8 and ISC's dhcpd on a RedHat 7.2=20
>>system several years ago. This system is on a small and isolated LAN=20
>>used by our hardware department to test returned systems. They
recently=20
>>upgraded the system to RedHat 9 (bind-9.2.1-16) at which time DDNS=20
>>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.


--=20

Regards,

Scott Dudley


This message is for the designated recipient only and may contain =
privileged, proprietary, or otherwise private information.  If you have =
received it in error, please notify the sender immediately and delete =
the original.  Any other use of the email by you is prohibited.