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): bind-9.2.4-8_FC3 How reproducible: Always. 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 68.122.205.66#53 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 68.122.205.67#53: failed while receiving responses: permission denied Feb 11 09:41:17 ns1 named[15772]: transfer of 'biospectra.com/IN' from 68.122.205.67#53: 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.
The ownership of $ROOTDIR/var/named was changed to root:named to address known security vulnerabilities; the default is maximum security. 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.
Thank you for the prompt info. On my part, I will get up to speed with SE Linux to increase my system security.
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 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.