Bug 663112

I initially reported this on the CentOS list along with the suggested workaround:

http://lists.centos.org/pipermail/centos/2010-December/102882.html

I can confirm this issue on my RHEL 5.5 box.

--
Eero

You can workaround this bug if you set "files 4096;" option in the options {} section in your named.conf.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

This is a regression from RHBA-2009-0246 which has open files limit set to
"unlimited" by default

(In reply to comment #6)
> This is a regression from RHBA-2009-0246 which has open files limit set to
> "unlimited" by default

To be precise, this is not regression from RHBA-2009-0246, let me explain this issue in detail.

There were two bugs in RHEL-5 version of BIND related to "unlimited" open limit by default:

1. by default bind set limit to 1024
2. there is an issue in the kernel which prevents to set limits to "unlimited" (http://kerneltrap.org/mailarchive/linux-kernel/2008/9/9/3238694).

In the RHBA-2009-0246 we fixed only the "1.", the second issue is still present. Rebase from 9.3.4 to 9.3.6 version exposes this bug because new BIND issues warning when files limit is too low. So I would rather not call this bug as Regression because the second issue was never fixed.

Removing Regression keyword.

(In reply to comment #3)
> You can workaround this bug if you set "files 4096;" option in the options {}
> section in your named.conf.

Should all users apply this workaround, or is it strictly only necessary on high-volume servers?
(Can the limit only be hit with ~1024 concurrent connections?)

(In reply to comment #15)
> (In reply to comment #3)
> > You can workaround this bug if you set "files 4096;" option in the options {}
> > section in your named.conf.
> 
> Should all users apply this workaround, or is it strictly only necessary on
> high-volume servers?
> (Can the limit only be hit with ~1024 concurrent connections?)

Users should apply this workaround when recursive server denies clients and system log (/var/log/messages) contains errors from named daemon which say certain operations fail due file limit.

If you don't see any error in the log, you don't have to apply the workaround.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0254.html