alexm at ndtel.com
Mon Mar 22 19:33:01 UTC 2010
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
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?
On Mar 22, 2010, at 1:43 PM, Alex Moen wrote:
> First of all, forgive the cross post... You will understand why in a
> 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.
> bind-users mailing list
> bind-users at lists.isc.org
I'm not overweight, your aspect ratio is wrong!
More information about the dhcp-users