Bug 500896 - Single Zone File Error Causes Full BIND Failure
Single Zone File Error Causes Full BIND Failure
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Adam Tkac
Martin Cermak
:
Depends On:
Blocks: 623673 657265 703411
  Show dependency treegraph
 
Reported: 2009-05-14 15:02 EDT by Doug M
Modified: 2012-07-11 03:19 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A new option, called DISABLE_ZONE_CHECKING, has been added to /etc/sysconfig/named. This option adds the possibility to bypass zone validation via the named-checkzone utility in initscript and allows to start named with misconfigured zones.
Story Points: ---
Clone Of:
: 623673 (view as bug list)
Environment:
Last Closed: 2011-01-13 17:25:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doug M 2009-05-14 15:02:58 EDT
Description of problem:
BIND startup script /etc/init.d/named runs "named-checkconf -z" before starting named.  If any zone file has a single error, it aborts the startup of BIND, thus making all zones unavailable.  


Version-Release number of selected component (if applicable):
bind-9.3.4-10.P1.el5

How reproducible:
Restart bind with an error in any zone.

Steps to Reproduce:
1.  Introduce an error into a single zone file.
2.  service named restart
3.  BIND does not start
  
Actual results:
BIND is not running, denying all DNS service.

Expected results:
BIND should load good zones and be running.

Additional info:
The init.d script for BIND is over 300 lines long and includes risky functionality that is not required by a mission-critial network infrastructure DNS server.
Comment 1 Adam Tkac 2009-05-18 06:54:15 EDT
This is a feature, not a bug. It is far more secure to report misconfiguration in zone file instead of silently ignore it.

It is possible to add new variable to /etc/sysconfig/named to disable configuration checking but it won't be default behavior.
Comment 2 Doug M 2009-05-26 22:36:24 EDT
We have several hundred zone files.  If one of them has a single typo, then all of them will fail to load on named restart.  If you want to fail just the erroneous zone for security, fine, even though this is a partial denial of service.  But please do not fail all zones and not even let BIND run.
Comment 3 Adam Tkac 2009-05-27 04:11:43 EDT
I wonder how did you hit this problem during restart.

If the first start was successful then the second start will be fine if you don't manually edit the zone file.

If you would like to manually edit the zone file while the server runs then you should use one of the two approaches:
1. if you have DDNS enabled for a zone
- run "rndc freeze <zonename>"
- edit the zone
- run "rndc thaw <zonename>"
2. if you don't have DDNS enabled
- edit the zone
- run "rndc reload <zonename>

If you misconfigure the zone then the old version is kept loaded (and error message is written to the log). Approach written above minimizes your DNS outage windows and you won't hit this "problem" (as I wrote in comment #1 this is actually a feature).

In all cases, option which disables zone syntax checking during server start will be added in future.
Comment 4 Doug M 2009-05-27 14:58:09 EDT
Sure, our system is a bit more complex as we sync zones out of Subversion.  After each update it does a "service named reload".  So the zone appears to BIND to have locally edited.  Unfortunately BIND restarts can (and have) occurred due to kernel OOPS, a UPS problem, general system reboot, or human error, and we're just looking to be reliable in the face of the unexpected.  It is the behavior during a "service named restart" (or reboot) that concerns me the most.

The good news is the latest kernel updates seem to have cured the OOPSes.

Any idea when the option change might be tested/released?  I'm holding all our DNS servers on RHEL4 right now and would like to move to RHEL5.

Thanks,
Doug
Comment 5 Adam Tkac 2009-05-28 11:13:12 EDT
(In reply to comment #4)
> Any idea when the option change might be tested/released?  I'm holding all our
> DNS servers on RHEL4 right now and would like to move to RHEL5.
> 
> Thanks,
> Doug

Unfortunately I don't have idea when update will be released. If you are the Red Hat customer and you have a subscription open a ticket in the issue tracker (or contact your support representative), please. Problems which go through support representative and issue tracker have higher priority.
Comment 6 RHEL Product and Program Management 2009-11-06 13:47:16 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 12 Martin Cermak 2010-10-29 08:59:02 EDT
=> VERIFIED
Comment 13 Martin Cermak 2010-11-09 03:50:20 EST
Reverified after rebase: https://tcms.engineering.redhat.com/run/14317/?from_plan=2749 for bind-9.3.6-15.P1.el5.
Comment 15 errata-xmlrpc 2011-01-13 17:25:00 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0032.html

Note You need to log in before you can comment on or make changes to this bug.