Introduction
After installing Vesta Control Panel (VestaCP), DNS records may appear correctly in the control panel but changes may not be reflected when querying the domain.
One possible cause is an AppArmor permission restriction preventing the BIND DNS server from accessing the DNS zone files. In this situation, DNS changes made through VestaCP may not be loaded correctly by BIND.
This guide explains how to identify and resolve this type of DNS permission issue by allowing BIND to access the required zone files.
Prerequisites
Before proceeding, make sure you have:
- A server running VestaCP.
- BIND9 installed and configured as the DNS service.
- Root or sudo access to the server.
- Access to the server’s system logs.
- AppArmor enabled on the server.
- The location of the BIND DNS zone files.
You can check the BIND configuration to identify the zone-file locations:
sudo vi /etc/bind/named.conf
Look for the relevant zone configuration and the associated zone-file path.
Implementation
Step 1: Check the System Logs
First, check the system log for BIND or AppArmor-related errors:
sudo grep -iE 'named|apparmor|denied' /var/log/syslog
If AppArmor is blocking BIND from accessing the zone files, you may see messages containing DENIED.
Step 2: Check the AppArmor Configuration
The AppArmor local configuration for BIND is normally located at:
/etc/apparmor.d/local/usr.sbin.named
Open the file:
sudo vi /etc/apparmor.d/local/usr.sbin.named
Add an AppArmor rule that permits BIND to access the required zone-file directory.
For example, if the VestaCP DNS zone files are stored under /home, the following rule can be used:
/home/** rwm,
Important: Do not add a broad path unless it is actually required by your BIND configuration. Prefer granting access to the specific DNS zone directory whenever possible.
Step 3: Reload the AppArmor Profile
After updating the configuration, reload the BIND AppArmor profile:
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.named
Verify that AppArmor has loaded the profile successfully.
You can also check the profile status:
sudo aa-status
Step 4: Restart BIND
Restart the BIND9 service:
sudo systemctl restart bind9
On older systems, the following command may also be used:
sudo service bind9 restart
Check the service status:
sudo systemctl status bind9
Step 5: Verify DNS
After restarting BIND, verify that the DNS server is loading the zone correctly.
You can query the local DNS server using:
dig @127.0.0.1 example.com
Replace example.com with your actual domain.
You can also check whether BIND loaded the zone successfully:
sudo journalctl -u bind9
If the DNS server is authoritative for the domain, verify the updated record from an external DNS resolver as well.
Conclusion
When DNS changes made through VestaCP are not reflected, the problem may be related to BIND being unable to access the DNS zone files because of AppArmor restrictions.
Checking /var/log/syslog, identifying DENIED messages, allowing BIND to access the required zone-file directory, reloading the AppArmor profile, and restarting BIND can resolve this type of issue.
Always verify the actual zone-file location before modifying AppArmor rules and grant access only to the directories that BIND needs.
Frequently Asked Questions
1. Why are DNS changes in VestaCP not reflecting?
One possible reason is that BIND cannot access or load the DNS zone files. AppArmor restrictions, incorrect permissions, invalid zone files, or BIND configuration errors can all cause DNS changes to fail.
2. How can I check whether AppArmor is blocking BIND?
Check the system logs:
sudo grep -iE 'named|apparmor|denied' /var/log/syslog
Look for DENIED messages related to named or BIND.
3. Where is the AppArmor configuration for BIND?
The local customization file is normally:
/etc/apparmor.d/local/usr.sbin.named
The main profile is usually:
/etc/apparmor.d/usr.sbin.named