Again, sorry for the cross post here...
One other piece of information here that I failed to provide: my
workaround for the time being, which may shed some light on the
solution, maybe...
So, when I run into this problem, I need it repaired asap, as it is
breaking POTS to our customers. So here's what I do:
1. Stop the DHCP process.
2. Clear out the lease associated with the MAC address... manually...
out of the dhcpd.leases file. I know, I know...(sound of me slapping
my own hand).
3. Stop the DNS process.
4. Clear out the information out of the ndb files pertaining to the
client name. This is a known value based on the client MAC address.
(Again, the hand slap)
5. Restart the DNS server.
6. Restart the DHCP server.
7. Force the client to do a DHCP request. This recreates the lease on
the DHCP server, which then updates DDNS on the DNS server,
successfully. This fixes the DNS problem for this client.
So, I can do it manually, but why can't the DHCP server request the
same thing to be done automagically? Where is the provision for this
type of process?
Thanks...
Alex
On Mar 22, 2010, at 1:43 PM, Alex Moen wrote:
First of all, forgive the cross post... You will understand why in a
minute.
I am experiencing a problem with DDNS. We have access equipment
that is performing DHCP snooping, and adding circuit and client
identifiers for CALEA purposes to the DHCP conversations. Also, we
make decisions based on the circuit id to determine what pool the
client belongs in.
A change from the manufacturer has caused the client IDs to change
if the client configuration is changed. This change causes a couple
of things to happen, and this is where my problem lies:
1. Client requests assigned IP address after provisioning has
changed client ID.
2. DHCP server NAKs based on the changed client ID.
3. Client and server process DISCOVER, OFFER, REQUEST, and ACK
sequence. Client is given a new IP address.
4. DHCP server attempts to change the DDNS information to DNS server.
5. DDNS update fails, with these in the DNS server log file:
Mar 18 10:55:46.770 update: info: client 10.4.0.4#44378: updating
zone 'rg/IN': update failed: 'name not in use' prerequisite not
satisfied (YXDOMAIN)
Mar 18 10:55:46.774 update: info: client 10.4.0.4#44379: updating
zone 'rg/IN': update failed: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)
Question: how do I fix this problem? Can I somehow force the DHCP
server to ignore the client ID and process only on the MAC address
and Circuit ID? And, why does the DNS server not accept the change
from an authorized DHCP server? How is a situation like this
supposed to be handled?
I am currently running BIND 9.2.4 and DHCP 3.0.3. I know these are
both very old versions (servers have been up for 1585 days and 1494
days respectively), and I plan on upgrading to current releases
during tomorrow's maintenance period, but before doing that I would
like to know if it will help...
TIA, and if anything else is needed, please let me know.... My
configs are available if needed, don't wanna create such a long post
if it's not needed.
Alex
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
----------------
I'm not overweight, your aspect ratio is wrong!
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
