Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 147824 - Slave DNS servers cannot transfer zones after update to bind-9.2.4-8_FC3.
Slave DNS servers cannot transfer zones after update to bind-9.2.4-8_FC3.
Status: CLOSED DUPLICATE of bug 145664
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Depends On:
  Show dependency treegraph
Reported: 2005-02-11 13:10 EST by Benjamin Baez
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:08:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Benjamin Baez 2005-02-11 13:10:37 EST
Description of problem:
Slave DNS servers cannot transfer zones after update to
bind-9.2.4-8_FC3.  Working fine for years until then.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. /etc/init.d/named restart
Actual results:
Feb 11 09:41:16 ns1 named[15772]: zone biospectra.com/IN: refresh:
unexpected rcode (SERVFAIL) from master
Feb 11 09:41:17 ns1 named[15772]: dumping master file: tmp-XXXXExhfnE:
open: permission denied
Feb 11 09:41:17 ns1 named[15772]: transfer of 'biospectra.com/IN' from failed while receiving responses: permission denied
Feb 11 09:41:17 ns1 named[15772]: transfer of 'biospectra.com/IN' from end of transfer

Expected results:
Feb 11 09:46:52 ns1 named[15954]: zone biospectra.com/IN: transferred
serial 2004062200

Additional info:

RESOLUTION: Directory owner of /var/named had changed from named to
root.  Group was still named.  Fixed by chown -R named /var/named
Happened on all three systems that were updated.  Tape backup showed
that ownership permissions were correct immediately before bind update.
Comment 1 Jason Vas Dias 2005-02-11 13:22:38 EST
The ownership of $ROOTDIR/var/named was changed to root:named to 
address known security vulnerabilities; the default is maximum
If you have SELinux enabled, you need to enable the 
   'named_write_master_zones' boolean :
   # setsebool named_write_master_zones 1
   or using the 'system-config-security' GUI .
In an attempt to minimise the impact of this change, I added the
functionality to make the /etc/init.d/named script automatically 
set the $ROOTDIR/var/named ownership to named:named if SELinux is
enabled and named_write_master_zones is 1, or to root:named if
named_write_master_zones is 0 . In bind-9.2.4-8_FC3, there is no
functionality to do this if SELinux is not enabled. 
In the forthcoming bind-9.2.4-9_FC3, I added support for a
'DDNS_ENABLED=yes' setting in /etc/sysconfig/named which will make 
the startup script set the correct ownership if SELinux is not 
enabled . I'll be releasing bind-9.2.4-9_FC3 into FC3 updates in
a few days once QA testing is complete and will update this bug
when it is done.
Sorry for any trouble this has caused - the change was
mandated by our security vulnerability response team.

Comment 2 Benjamin Baez 2005-02-13 14:46:23 EST
Thank you for the prompt info.  On my part, I will get up to speed
with SE Linux to increase my system security.
Comment 3 Jason Vas Dias 2005-02-25 14:58:13 EST
This bug is now fixed with bind-9.2.5rc1-1 (FC3) / bind-9.3.1rc1-1 (FC4).

If SELinux is not disabled, the setting of 'named_write_master_zones'
will determine whether $ROOTDIR/var/named has ownership named:named
(named_write_master_zones=1) or root:named (named_write_master_zones=0).

If SELinux is disabled, if the variable 'ENABLE_ZONE_WRITE' is 
set to 'yes'/'1' in /etc/sysconfig/named, then the ownership 
of  $ROOTDIR/var/named is set to named:named; if  'ENABLE_ZONE_WRITE'
is set to 'no'/'0', the ownership of  $ROOTDIR/var/named is set to
root:named; if ENABLE_ZONE_WRITE is not set, the ownership of
$ROOTDIR/var/named is unchanged. 

This automatic setting of the $ROOTDIR/var/named was to minimise
the impact of the change of ownership of $ROOTDIR/var/named to
root:root to counter known security vulnerabilities as mandated 
by our security response team.

Now, with SELinux, DDNS and slave zone writes can be enabled through
use of the system-config-security GUI only, without extra steps 
having to be taken by the administrator to set the ownership of the
/var/named directory.

*** This bug has been marked as a duplicate of 145664 ***
Comment 4 Red Hat Bugzilla 2006-02-21 14:08:10 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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