failed forwarder timeout
Chris Buxton
cbuxton at menandmice.com
Wed Sep 20 18:58:51 UTC 2006
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
>
>
>
More information about the bind-users
mailing list