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!
AWS Android Ansible Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Consul Container Containers CouchDB DB DNS Database Databases Docker ELK ElasticSearch Elasticsearch Filebeat FreeBSD GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Icingaweb2 InfluxDB Internet Java Kibana Kubernetes LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Rancher SSL Security Shell SmartOS Solaris Surveillance SystemD TLS Tomcat Ubuntu Unix VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder