Bind9 DNS service failing to start after zone record edit in CyberPanel

by

The Bind9 (Named) DNS service fails to start after modifying zone records in CyberPanel because the underlying zone file syntax was corrupted during the write operation or CyberPanel generated an invalid configuration structure. Bind9 performs strict semantic and syntactic checks on both /etc/named.conf (or /etc/bind/named.conf) and individual zone files during startup, immediately aborting the process if it encounters unescaped characters, missing trailing dots on FQDNs, invalid serial number formats, or missing SOA/NS records. Additionally, CyberPanel occasionally fails to apply correct file ownership (named:named or bind:bind), causing permission-denied errors when the daemon attempts to read the modified zone file.

Quick Fix

Identify the exact line causing the syntax error by running the Bind9 configuration checker, fix or roll back the bad record in the flagged zone file, and restart the service:

named-checkconf -z /etc/named.conf || named-checkconf -z /etc/bind/named.conf
systemctl restart named || systemctl restart bind9

Step-by-Step Resolution

  1. **Locate the Syntax Error with named-checkconf**
  • Run the built-in configuration validator to check all included zone files for errors:
# For RHEL/AlmaLinux/Rocky Linux:
named-checkconf -z /etc/named.conf

# For Ubuntu/Debian:
named-checkconf -z /etc/bind/named.conf
  • The output will output the exact file path, line number, and error reason (e.g., /var/named/example.com.zone:14: unexpected token).
  1. **Validate the Specific Zone File with named-checkzone**
  • Target the broken zone file directly to confirm record-level issues:
named-checkzone example.com /var/named/example.com.zone
  • Common output errors to look for:
  • NS record 'ns1' has no address record (A/AAAA)
  • zone [example.com/IN](https://example.com/IN): has no NS records
  • ttl for example.com. is not valid
  1. Correct Zone Syntax in CyberPanel or CLI
  • Open the zone file in a text editor:
nano /var/named/example.com.zone
  • Fix common CyberPanel editing glitches:
  • Missing Trailing Dots: Ensure fully qualified domain names in CNAME, MX, or NS records end with a dot (e.g., mail.example.com.).
  • Malformed Serial: Ensure the SOA serial number follows the YYYYMMDDNN format and is an integer.
  • Unescaped Quotes in TXT/SPF: Ensure TXT records containing special characters are wrapped in quotation marks:
example.com. IN TXT "v=spf1 a mx ip4:192.0.2.1 ~all"
  • Save the file and exit.
  1. Fix File Permissions and Ownership
  • CyberPanel sometimes resets zone file permissions to root:root when saving from the web GUI, preventing Bind9 from reading the file.
  • Restore correct ownership and permissions:
# RHEL / AlmaLinux / Rocky Linux
chown named:named /var/named/example.com.zone
chmod 640 /var/named/example.com.zone

# Ubuntu / Debian
chown bind:bind /etc/bind/zones/example.com.zone
chmod 640 /etc/bind/zones/example.com.zone
  1. Restart Service and Verify Status
  • Restart the DNS daemon:
systemctl restart named || systemctl restart bind9
  • Check status to confirm active execution:
systemctl status named || systemctl status bind9
  • Verify that the step was successful: The command output should display active (running) without any red exit codes or log warnings regarding zone loading failures.
See also  How to enable HTTP/2 on secondary domain vhosts in CyberPanel without GUI reset

Why This Fails for Some Users

  • CyberPanel Database Sync Discrepancy: CyberPanel stores DNS records in its MySQL database (cyberpanel -> domains_dnsrecords) and overwrites physical zone files when modifications are submitted via the GUI. If you manually fix the file on disk without updating the database, CyberPanel will re-inject the broken syntax the next time any DNS record is edited via the web panel.
  • Chrooted Bind Environments: On systems running named-chroot.service, Bind operates inside a isolated jail environment (typically /var/named/chroot/). Edits made to non-chrooted paths (/var/named/) will have no effect, or permissions applied to the host path will fail inside the chroot jail context.
  • AppArmor / SELinux Restraints: On AlmaLinux/RHEL with SELinux enabled in Enforcing mode, saving a new zone file via CyberPanel can assign an incorrect SELinux security context (e.g., admin_home_t instead of named_zone_t), causing Bind9 to fail with a silent permission error upon startup. Restoring context via restorecon -v /var/named/*.zone is required.

Leave a Comment