<p>If a given forwarder is "bad " it get its round trip time, rtt, set high and will not be used until that comes back down via the normal rtt decay mechanism in BIND. I have not tested the behaviour when all are down. My assumption would be that if all are down they will all have to be tried before going to NS or there is no way of knowing when the forwarders are back. </p>
<p>In your case if you have a limited number of servers a quick removal of the forwarders may be the quickest way to restore service.</p>
<p>-Ben Croswell</p>
<div class="gmail_quote">On Nov 1, 2011 10:03 AM, "Will Lists" <<a href="mailto:listswill@gmail.com">listswill@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ben,<div><br></div><div>I seem to recall reading at some point in the past that after X amount of time, BIND would stop trying to contact servers it figured to be dead (at least it would stop trying for some amount of time). Is that in fact the case and would it eventually come into play here? Any configurable options here, if this behavior does exist?<div>
<br></div><div>It almost seems like the best way to handle this scenario, in the event of a real failure of one or more external servers that typically act as forwarders, would be to quickly modify the configuration internally to just stop forwarding. Thoughts?</div>
<div><br></div><div>Thanks.</div><div><br></div><div><br></div><div>-Will</div><div><br><br><div class="gmail_quote">On Tue, Nov 1, 2011 at 8:54 AM, Ben Croswell <span dir="ltr"><<a href="mailto:ben.croswell@gmail.com" target="_blank">ben.croswell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>If you have a global forwarder in place there are two options that affect its use. Forward first, the default, and forward only.<br>
Forward first will exhaust the forwarders you have and then attempt to follow NS records. Forward only will only use forwarders. </p>
<p>The delay you are seeing is likely the delay in exhausting the forwarders before attempting the roots.</p>
<p>-Ben Croswell</p>
<div class="gmail_quote">On Nov 1, 2011 9:23 AM, "Will Lists" <<a href="mailto:listswill@gmail.com" target="_blank">listswill@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We recently tried a test to see how our internal servers would react to a loss of their external peers, with the goal being that the internal servers would switch from forwarding to doing recursive queries for clients. Normally, the internal servers forward to the external servers. To simulate the loss of the external servers, we pushed a new firewall rule that blocked port 53 to the external servers from the internal servers. That did seem to cause the internal servers to start using the root servers in a recursive manner.<div>
<br></div><div>We did see that some recursive queries were answered, eventually, though usually much, much slower than if the request had been forwarded as normal to the external servers. We saw traffic (lots of traffic) going across the firewall to the roots as well as multiple domain specific name servers, so that flow path is working as best as I can tell. All servers are running BIND 9.7.4.</div>
<div><br></div><div>The issue we saw was that the queries would time out more often than not and on the off chance they did get an answer back to the requesting client, it was very slow after several retries. </div><div>
<br></div><div>Am I missing something in the named.conf file? Is there something specific I should be looking for in the syslog or daemon.log?</div><div><br></div><div><br></div><div>The relevant portion of the named.conf file for the INTERNAL view is below:</div>
<div><br></div><div><div><br></div><div> forwarders { NS2; NS1; };</div><div> forward first;</div><div> allow-recursion { <a href="http://10.0.0.0/8" target="_blank">10.0.0.0/8</a>; <a href="http://192.168.0.0/16" target="_blank">192.168.0.0/16</a>; <a href="http://172.16.0.0/12" target="_blank">172.16.0.0/12</a>; }; </div>
<div> recursion yes;</div><div><br></div><div> // zone: . [hint]</div><div> include "...";</div></div><div><br></div><div><br></div><div>The hints DB file is current as of the version of BIND in use (2011060800).</div>
<div><br></div><div><br></div><div>Thanks.</div><div><br></div><div>-Will</div>
<br>_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to 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" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br></blockquote></div>
</blockquote></div><br></div></div>
<br>_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to 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" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br></blockquote></div>