<div dir="ltr">Hi,<div><br></div><div>Thank you for your reply.<br></div><div><br></div><div>1. We got the last version of root.cache file.</div><div> </div><div>Using dig, only <a href="http://d.root-servers.net">d.root-servers.net</a> doesn't respond at all.</div><div>All other root servers answers correclty :</div><div> </div><div>e.g</div><div># dig ns . @<a href="http://202.12.27.33">202.12.27.33</a> +short</div><div><a href="http://b.root-servers.net">b.root-servers.net</a>.</div><div><a href="http://l.root-servers.net">l.root-servers.net</a>.</div><div><a href="http://d.root-servers.net">d.root-servers.net</a>.</div><div><a href="http://g.root-servers.net">g.root-servers.net</a>.</div><div><a href="http://a.root-servers.net">a.root-servers.net</a>.</div><div><a href="http://j.root-servers.net">j.root-servers.net</a>.</div><div><a href="http://h.root-servers.net">h.root-servers.net</a>.</div><div><a href="http://m.root-servers.net">m.root-servers.net</a>.</div><div><a href="http://e.root-servers.net">e.root-servers.net</a>.</div><div><a href="http://k.root-servers.net">k.root-servers.net</a>.</div><div><a href="http://f.root-servers.net">f.root-servers.net</a>.</div><div><a href="http://i.root-servers.net">i.root-servers.net</a>.</div><div><a href="http://c.root-servers.net">c.root-servers.net</a>.</div><div><br></div><div>2. max-cache-size is currently fixed at 200M. We have got this value since a few years and we had never problems with it.</div><div>When I run 'rndc dump' command, the result file size is less than 100MB.</div><div><br></div><div>3. No, I didn't follow this advice, because usually this message appears only during 'Water Torture Attack'.</div><div>And with the current cache problem, this message doesn't appears each time.</div><div><br></div><div>4. We only updated the root.cache file. And since we have got a lot of warnings but we don't know if this is the root cause!</div><div>Our servers are VMWare VM on RHEL 6.6 / 4GB of RAM with a 10GB network connectivity </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-21 15:18 GMT+02:00 Warren Kumari <span dir="ltr"><<a href="mailto:warren@kumari.net" target="_blank">warren@kumari.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Aug 21, 2017 at 4:33 AM, Daniel Rodrigues <<a href="mailto:dro1976@gmail.com">dro1976@gmail.com</a>> wrote:<br>
> Hello guys,<br>
><br>
><br>
><br>
> We are facing to an important issue which is strongly annoying us on our DNS<br>
> resolvers. We saw our cache decrease and we got lot of SERVFAIL/recursion<br>
> during this period. The only way to solve it is to flush cache or reboot<br>
> BIND. Our version is 9.9.9-P8 running on RHEL 6.6. We already got it 6 times<br>
> in 1 week on different servers.<br>
><br>
> Here some logs when the problem appears :<br>
<br>
<br>
</span>Some questions:<br>
1: What do you have in your hints file? What do you get if you run<br>
"dig ns . @<address>" where<br>
<address> are the addresses in the hints file.<br>
<br>
2: Have you manually configured / changed the max-cache-size ? If so,<br>
er, why and to what?<br>
<br>
<br>
3: Do you usually get the "maximum number of FD events (64) received" message?<br>
Have you followed the advice in<br>
<a href="https://kb.isc.org/article/AA-00716/0/Since-upgrading-to-BIND-9.9-Im-seeing-maximum-number-of-FD-events-64-received.html" rel="noreferrer" target="_blank">https://kb.isc.org/article/AA-<wbr>00716/0/Since-upgrading-to-<wbr>BIND-9.9-Im-seeing-maximum-<wbr>number-of-FD-events-64-<wbr>received.html</a><br>
 ?<br>
<br>
and, the obvious 4: What changed recently? What sort of boxes are<br>
these? What is their network connectivity like?<br>
<br>
W<br>
<span class=""><br>
><br>
><br>
><br>
> named[10616]: database: warning: delete_node: dns_rbt_findnode(nsec):<br>
> partial match<br>
><br>
> named[10616]: general: warning: checkhints: unable to get root NS rrset from<br>
> cache: not found<br>
><br>
> general: info: sockmgr 0x7f4419f240f0: maximum number of FD events (64)<br>
> received<br>
><br>
><br>
><br>
> Below one link to see one cacti’s screen showing the performance:<br>
><br>
> <a href="https://drive.google.com/file/d/0B3pglqx0sbOiN3ZWQmM3MDdYOTQ/view?usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/file/<wbr>d/<wbr>0B3pglqx0sbOiN3ZWQmM3MDdYOTQ/<wbr>view?usp=sharing</a><br>
><br>
><br>
><br>
><br>
> Do you have any idea to solve it definitively ? Is it an exploit bug ?<br>
><br>
> Thanks for you help.<br>
><br>
><br>
><br>
><br>
</span>> ______________________________<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">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>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
I don't think the execution is relevant when it was obviously a bad<br>
idea in the first place.<br>
This is like putting rabid weasels in your pants, and later expressing<br>
regret at having chosen those particular rabid weasels and that pair<br>
of pants.<br>
   ---maf<br>
</font></span></blockquote></div><br></div>