<div dir="ltr">Thanks for the insight. <div>I added the following rule</div><div><div>sudo firewall-cmd --permanent --direct --get-all-rules</div></div><div>[sudo] password for admin:<br></div><div><div>ipv4 filter OUTPUT 0 -d 10.10.10.100 -p tcp -m tcp --dport=53 -j ACCEPT</div></div><div>where 10.10.10.100 is our DNS master, still receiving the error. </div><div><br></div><div>I found a solution for RHEL5/6, </div><div>Root Cause</div><div>•In socket_send() function the lock is not taken when doio_send() is invoked.</div><div>•This makes possible for two or more threads to invoke doio_send() simultaneously, resulting in the race which caused the error to appear on the logfile</div><div><br></div><div>but my environment is latest RHEL7. </div><div><br></div><div><div>named: zone refresh: failure results in the operation to be canceled on RHEL5/6 </div><div><br></div><div>$ Solution Verified - Updated March 5 2014 at 5:39 AM - English </div><div><br></div><div>Environment</div><div>•Red Hat Enterprise Linux 5 </div><div>•bind-9.3.4-10.P1.el5</div><div>•Red Hat Enterprise Linux 6</div><div>•bind-9.7.0-5.P2.el6</div><div><br></div><div>Issue</div><div><br></div><div>•named: zone refresh: failure ... operation canceled</div><div><br></div><div><br></div><div>Raw</div><div>Jan 1 00:00:00 xxx named[xxxx]: zone xxx.xxx.xxx.in-addr.arpa/IN: refresh: failure trying master xxx.xxx.xxx.xxx#53 (source xxx.xxx.xxx.xxx#0): operation canceled</div><div><br></div><div>Resolution</div><div>•For RHEL5, RHBA-2012:0254-1 at <a href="http://rhn.redhat.com/errata/RHBA-2012-0254.html">http://rhn.redhat.com/errata/RHBA-2012-0254.html</a></div><div>•For RHEL6, RHBA-2011:1697-2 at <a href="http://rhn.redhat.com/errata/RHBA-2011-1697.html">http://rhn.redhat.com/errata/RHBA-2011-1697.html</a></div><div><br></div><div>Root Cause</div><div>•In socket_send() function the lock is not taken when doio_send() is invoked.</div><div>•This makes possible for two or more threads to invoke doio_send() simultaneously, resulting in the race which caused the error to appear on the logfile</div></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 21, 2016 at 3:10 PM, Mark Andrews <span dir="ltr"><<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
In message <CALg_j4-ibtaRv2aiKkS2Za6YBtiC<wbr>vkRL7vBJvZQqqXXYhhJWCQ@mail.<wbr>gmail.c<br>
<span>om>, schilling writes:<br>
><br>
> We are experiencing this bug with BIND 9.9.4-RedHat-9.9.4-29.el7_2.4<br>
> (Extended Support Version) running as slave on Red Hat Enterprise Linux<br>
> Server release 7.2 (Maipo).<br>
> disable firewalld seems to stopped the error logging. But as soon as<br>
> re-enable firewalld, the messages came back.<br>
<br>
</span>Well have you thought that your firewall rules could be wrong? That<br>
they are blocking legitimate traffic? That they need to be re-written<br>
to account for legitimate traffic?<br>
<br>
Mark<br>
<div class="gmail-m_-1659065976547117418HOEnZb"><div class="gmail-m_-1659065976547117418h5"><br>
> Do we have any update or fix on this?<br>
><br>
> Best,<br>
><br>
> Shiling Ding<br>
><br>
> On Wed, Feb 4, 2015 at 2:59 PM, Raymond Drew Walker <<a href="mailto:Ray.Walker@nau.edu" target="_blank">Ray.Walker@nau.edu</a>><br>
> wrote:<br>
><br>
> > Howdy,<br>
> ><br>
> > We’ve noticed the error message "refresh: failure trying master<br>
> ...:<br>
> > operation canceled” in our logs debugged from some slaves not up<br>
> dating DS<br>
> > records in some zones.<br>
> ><br>
> > Looking into this error over at: <a href="https://deepthought.isc" rel="noreferrer" target="_blank">https://deepthought.isc</a>.<br>
> > org/article/AA-01213/0/What-ca<wbr>uses-refresh:-failure-<br>
> > trying-master-...:-operation-c<wbr>anceled-error-messages.html<br>
> ><br>
> > So far we have updated the RHEL6 kernel on the slaves which did nothing.<br>
> ><br>
> > We have disabled the netfilter module which does seem to resolve the iss<br>
> ue<br>
> > in our limited testing, but our sysadmins would like to continue use of<br>
> > this module for other reasons.<br>
> ><br>
> > My question:<br>
> > What information would be most useful in our incoming bug report?<br>
> ><br>
> > —<br>
> > Raymond Walker<br>
> > Software Systems Engineer StSp<br>
> > ITS Northern Arizona University<br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a> to<br>
> > unsubscribe from this list<br>
> ><br>
> > bind-users mailing list<br>
> > <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
> > <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a><br>
> ><br>
><br>
<br>
</div></div><span class="gmail-m_-1659065976547117418HOEnZb"><font color="#888888">--<br>
Mark Andrews, ISC<br>
1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
PHONE: <a href="tel:%2B61%202%209871%204742" value="+61298714742" target="_blank">+61 2 9871 4742</a> INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
</font></span></blockquote></div><br></div></div>