Log entries "bind update on ... rejected: BNDUPD without CHADDR"

Gregory Sloop gregs at sloop.net
Mon Apr 29 23:57:10 UTC 2019

A quick google search got me this:


"This means your failover server transmitted an update for a lease
that was in the ACTIVE, EXPIRED, or RELEASED states, and did not
contain a chaddr option."

Given that - I'd guess it has to do with how you're moving/mirroring the leases file from the current active servers to the new fail-over pair.

I'm sure someone else will give you more detail, but that is probably helpful and a good place to start.


I have a primary and secondary dhcpd server that I have set up as central dhcp servers for a bunch of relays.  The servers come up, and they communicate properly.  The trouble is they keep reporting:
“bind update on ww.xx.yy.zz from <my failover> rejected: BNDUPD without CHADDR”
I do NOT want to update dns: dns is not relevant here.
Question number one:
              Is this “error” due to dhcpd failing to update the dns server, or some sort of socket binding issue?  (overuse of the word “bind” perhaps?)
In both of the dhcpd.conf files, I have the following lines:
ddns-update-style none;
ddns-updates off;
Question number two:
              Why would dhcpd try to send updates if they are turned off?
Further information:
I am running isc bind produced by centos: 4.2.5.  I will also be seeking answers there in case it’s a question of their compiling and bollixing it up.
I am currently consolidating a number of remotely located dhcp servers that are very old (Solaris 10 running bind 3.0.4 ).  At present the remote servers are having dhcp queries relayed to them by the various equipment we support.  Once this is done, we will simply change the relay ip to the new servers.  
The procedure I am using: replicate all dhcpd.leases, filtering out deprecated and dhcp server specific content, copying new dhcpd.leases to both dhcp development servers, and starting dhcpd.
Enclosed is a shortened, sanitized sample dhcpd.conf file.  The only difference between primary and secondary is the address and peer addresses are swapped.  I have ensured peer tcp ports are not firewalled.
Thank you for  your time!

Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gregs at sloop.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20190429/e6177afc/attachment.html>

More information about the dhcp-users mailing list