Issues with BIND 9.5.0-P2

[cherrera156 at gmail.com]

Here in our site we have a similar problem. After setting a value of
2048 for ISC_SOCKET_FDSETSIZE in one of our 4 linux boxes acting as
resolvers, we see the number of connections reported by rndc go up
right to the defined recursive-clients value in named.conf (1000,
2000, etc). The other three boxes, without the 9.5.0-P2 version
maintain a value of about 300 connections. The problem is that the
patched server shows warning messages like this:

client xxx.xxx.xxx.xxx#51070: no more recursive clients: quota reached

I know that defining a value for ISC_SOCKET_FDSETSIZE smaller than the
value for recursive-clients will show the error "too many open files".

I know that those clients (hosted in our networks) could be abusing
our servers too, but I think that the behaviour of the patched server
is weird. Why the other 3 servers, with the same configuration,
receive less connections?

What I'm missing?

On 7 ago, 03:59, JINMEI Tatuya / 神明達哉 <Jinmei_Tat... at isc.org> wrote:
> At Thu, 7 Aug 2008 14:48:52 +0800,
>
> "Elias" <el... at streamyx.com> wrote:
> > Is there any change if you build named with/without threads (and with FD_SETSIZE=4096)?
> > --> have yet to try this. Will test and let you know.
>
> > How many queries per second is that server normally accepting?
> > --> we're seing about 4.2k - 5.5k requests per second.
>
> > What's the normal cache hit rate (you can identify it via rndc stats outputs)?
> > --> cache hit rate now is around 81.78%
>
> Okay, some more questions:
>
> - do you specify a sufficiently large value for max-cache-size? (maybe
>   if you can post your named.conf that would be helpful)
> - does the trouble keep happening, or is that something like a
>   spike-type trouble (which then subsides)?
> - if you perform 'rndc recursion' during the errors are happening, do
>   you see anything strange in the corresponding named.recursing file?
>   For example, are there clients that are too old, i.e., should be
>   timed out but not?
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.