Bug 511223

Summary: Improve bind logging functionality
Product: Red Hat Enterprise Linux 5 Reporter: David Kovalsky <dkovalsk>
Component: bindAssignee: Adam Tkac <atkac>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: benl, ovasik
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-21 14:25:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Kovalsky 2009-07-14 10:31:46 UTC
Today I was surprised why bind doesn't answer queries for my zone. It turned out to be bad ownership of file in /var/named/chroot/var/named.

If the file has ownership+perms of root.named (-rw-r-----), then it's correctly read. If it has ownership of root.root (-rw-r-----), then even though bind restarts without any warnings, an attempt to query fails (nothing logged). 

I suggest that bind emits a warning that file 'foo' can't be read. 

Reproducer:
1) Add domain into to named.conf
zone "my-domain.org" IN {
        type master;
        file "my-domain.org.zone";
}

2) Create my-domain.org.zone file in /var/named/chroot/var/named. If you're root, the default ownership+perms are root.root (-rw-r-----)

3) service named restart

4) # host my-domain.org 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

Host my-domain.org not found: 2(SERVFAIL)

5) chown root.named /var/named/chroot/var/named/my-domain.org ; service named restart ; 

6) # host my-domain.org 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

my-domain.org has address 1.2.3.4


Results:
bind logs nothing if it can't read it's configuration

Expected:
bind logs 'cannot read file my-domain.org.zone', or anything meaninful. Ideally at the time of the restart, as a service configuration, where part of the files are not readable, is meaningless. 

bind-9.3.4-10.P1.el5_3.1

Comment 1 Adam Tkac 2009-07-16 11:11:36 UTC
Please check your logs carefully. BIND writes message like

"Jul 16 13:04:23 rhel5 named[2812]: zone 0.0.127.in-addr.arpa/IN/localhost_resolver: loading master file named.local: permission denied"

to the system log (/var/log/messages). This is considered as non fatal error in all BIND versions. Closing as notabug.

Comment 2 David Kovalsky 2009-08-03 12:42:32 UTC
Hi Adam, 

you're right :-) I missed it in the logs - I was "eye grepping" for FAILED, but missed "permission denied". 

I think the bug is still valid though - the point is that bind should not start just like that if it's not fully functional. 
If some of the configuration files can not be read, the app cannot work as expected, and it should either:
 - bail out, report [FAILED], return non-zero return code and print an error
 or at least
 - print a warning during the startup to stderr. This is the way apache HTTP server works, btw.

It's very hard to debug (and do any changes!) if after every restart you carefully have to grep /var/log/messages to check if bind is actually doing what it should.

Comment 3 RHEL Program Management 2009-11-06 18:54:06 UTC
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 4 Adam Tkac 2010-06-28 11:49:30 UTC
This kind of errors can be handled via "named-checkconf" utility which is executed in initscript to verify the configuration is correct. The named-checkconf utility will be extended by a new parameter which will allow it to run under "named" user to catch this kind of errors.

I'm currently waiting for response from upstream if this new option is acceptable for them, without their approval it can't be added.

Comment 5 David Kovalsky 2010-06-30 09:38:22 UTC
Sounds like a good plan, thanks Adam!

Comment 6 Ondrej Vasik 2010-09-21 07:45:27 UTC
Upstream is not responding to that bugzilla, therefore I'm setting dev_nack instead of conditional nack. Fork is not a good idea here.