failed forwarder timeout

[Chris Buxton]

This is fixed in BIND 9.3, which re-implements the RTT algorithm for  
forwarders. (This was a feature of BIND 8 that was not recreated in  
BIND 9 until version 9.3.)

I don't believe the two second delay is configurable.

Very busy servers typically use forwarding if the upstream server has  
better bandwidth; otherwise, usually not. After all, one of the  
primary reasons for using forwarding is to aggregate caching, but if  
the servers configured to use a central forwarder are all really  
busy, the forwarder probably will have to have faster hardware, more  
RAM, and more available bandwidth to provide any real benefit. And it  
will have to be closely monitored to make sure it doesn't get  
overloaded and start hitting limits (like the one you mentioned).

Chris Buxton
Men & Mice
Take control of your network

On Sep 20, 2006, at 12:55 AM, Iain Pople wrote:

> Hi,
>
> We are running bind 9.2.4 on RHEL4 as a caching only name server. We
> have 2 forwarders listed. I have found that if one of the  
> forwarders is
> unreachable, then BIND still tries to query the first forwarder for
> every query before failing over to the second listed forwarder. This
> introduces a 2 second delay for every query.
>
> I assume that this behaviour is because BIND 9 ignores the RTT  
> value for
> forwarders.
>
> There is an interesting yet dangerous side effect of the 2 second  
> delay.
> If you have a large number of recursive queries to your server,  
> then the
> delay causes them to rapidly bank up, which means that you can exceed
> your limit for recursive-clients. At this point BIND stops answering
> queries and is essentially failing.
>
> - Has this behaviour been changed in more recent versions of BIND?
> - Is the 2 second timeout configurable?
> - Are there any strategies for dealing with this, or do busy servers
> generally turn off forwarding.
>
> thanks, Iain.
>
> -- 
> Iain Pople
> Systems Interface Technical Lead
> University of Melbourne
>
>
>