Switching from forwarding to recursion

[Ben Croswell]

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.

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.

-Ben Croswell
On Nov 1, 2011 10:03 AM, "Will Lists" <listswill at gmail.com> wrote:

> Ben,
>
> 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?
>
> 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?
>
> Thanks.
>
>
> -Will
>
>
> On Tue, Nov 1, 2011 at 8:54 AM, Ben Croswell <ben.croswell at gmail.com>wrote:
>
>> If you have a global forwarder in place there are two options that affect
>> its use. Forward first, the default, and forward only.
>> Forward first will exhaust the forwarders you have and then attempt to
>> follow NS records. Forward only will only use forwarders.
>>
>> The delay you are seeing is likely the delay in exhausting the forwarders
>> before attempting the roots.
>>
>> -Ben Croswell
>> On Nov 1, 2011 9:23 AM, "Will Lists" <listswill at gmail.com> wrote:
>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Am I missing something in the named.conf file?  Is there something
>>> specific I should be looking for in the syslog or daemon.log?
>>>
>>>
>>> The relevant portion of the named.conf file for the INTERNAL view is
>>> below:
>>>
>>>
>>>     forwarders { NS2; NS1; };
>>>     forward first;
>>>     allow-recursion { 10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12; };
>>>     recursion yes;
>>>
>>>     // zone: . [hint]
>>>     include "...";
>>>
>>>
>>> The hints DB file is current as of the version of BIND in use
>>> (2011060800).
>>>
>>>
>>> Thanks.
>>>
>>> -Will
>>>
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>> unsubscribe from this list
>>>
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>
>>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20111101/c4fecd10/attachment.html>