On a Bind master server installed on an Ubuntu 14.04 machine, it is pretty much "standard" to run everything within /etc/bind. As this is a master DNS server, the zone files are usually updated manually.
But if you run a master-slave-replication, do not use the same directory structure on the slave!
By troubleshooting a case, where the replication did not work and the zone files were not created on the slave server, I came across the following error message in syslog on the slave:
named: client 10.10.44.67#7865: received notify for zone 'example.com'
named: zone example.com/IN: Transfer started.
named: transfer of 'example.com/IN' from 10.10.44.67#53: connected using 10.10.44.68#33813
named: zone example.com/IN: transferred serial 2014090801
named: transfer of 'example.com/IN' from 10.10.44.67#53: Transfer completed: 1 messages, 33 records, 1170 bytes, 0.001 secs (1170000 bytes/sec)
named: zone example.com/IN: sending notifies (serial 2014090801)
named: dumping master file: /etc/bind/zones/tmp-kP27d0CASU: open: permission denied
kernel: [239980.946541] type=1400 audit(1410164178.794:90): apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/zones/tmp-kP27d0CASU" pid=319 comm="named" requested_mask="c" denied_mask="c" fsuid=111 ouid=111
Interesting. The master sends the notify for the zone and the slave receives the notify and the transfer is initiated. But when the slave tries to create the zonefile in /etc/bind/zones, a permission denied error arises. One line further the "blocker" is identified: apparmor.
Indeed, in the apparmor profile for /usr/sbin/named (/etc/apparmor.d/usr.sbin.named) does not allow the bind process to write anything into /etc/bind/:
# /etc/bind should be read-only for bind
# /var/lib/bind is for dynamically updated zone (and journal) files.
# /var/cache/bind is for slave/stub data, since we're not the origin of it.
# See /usr/share/doc/bind9/README.Debian.gz
As solution, one should use /var/lib/bind/(zones) as path for the zone files, which are dynamically created through the master-slave replication.
Marc from wrote on Mar 7th, 2015:
This just saved me lots of aggravation! Thanks for posting!
Personal Internet VMware PHP Linux Shell Bluecoat Proxy Windows Hardware Virtualization Nagios MySQL DB Monitoring Mail Android Network Wyse Hacks Tomcat Postgres Apple Mac Backup BSD ZFS Solaris SmartOS Unix Multimedia Perl Database MongoDB CMS OTRS FreeBSD Wordpress LXC Nginx Proxmox DNS Graphics GlusterFS Security Chef HAProxy Icinga Ansible HTML MariaDB Containers Rancher Docker AWS ELK Kibana Logstash Filebeat Varnish PGSQL PostgreSQL ElasticSearch CouchDB Bash Macintosh Container Minio Grafana InfluxDB Databases NFS OSSEC SystemD Java Zoneminder Surveillance Elasticsearch SSL TLS Icingaweb2 Cloud Wireless Kubernetes Ubuntu