Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

failed forwarder timeout

117 views
Skip to first unread message

Iain Pople

unread,
Sep 20, 2006, 3:55:42 AM9/20/06
to
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


Chris Buxton

unread,
Sep 20, 2006, 2:58:51 PM9/20/06
to
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

0 new messages