The BIND DNS server is failing to load zone files because it’s detecting an existing file with the same name but with content, which it interprets as a conflict.
Cause 1: Stale Zone Files on Secondary Servers
Diagnosis: On the secondary BIND server, check the zone file directory for the zone in question.
ls -l /var/named/zones/db.example.com
Look for a file with the correct name but potentially an older timestamp or different content than expected.
Fix: Remove the stale zone file from the secondary server.
rm /var/named/zones/db.example.com
This allows BIND to fetch the correct, up-to-date zone file from the primary server during its next zone transfer (AXFR/IXFR).
Why it works: Secondary DNS servers rely on zone transfers from primary servers. If a zone file was previously loaded and then deleted or modified on the primary, the secondary might still hold a ghost of the old file, causing this error when it tries to load the new data.
Cause 2: Accidental File Creation by BIND
Diagnosis: Examine the BIND process’s logs for messages indicating it tried to write to the zone file location. This often happens if BIND was configured to dynamically update zone files and encountered an issue.
journalctl -u named -f | grep "File already exists and is not empty"
Also, check file ownership and permissions in the zone file directory.
ls -ld /var/named/zones/
ls -l /var/named/zones/db.example.com
The named user should own these files.
Fix:
If BIND created the file erroneously, remove it and ensure the named user has correct ownership and permissions.
chown named:named /var/named/zones/db.example.com
chmod 644 /var/named/zones/db.example.com
rm /var/named/zones/db.example.com
Then, restart BIND.
systemctl restart named
Why it works: BIND, especially when configured for dynamic DNS updates (like with nsupdate), might create or modify zone files. If it encountered an error during a write operation, it might leave behind an incomplete or incorrectly created file. Removing it and ensuring proper permissions lets BIND properly manage the file.
Cause 3: Manual File Creation with Incorrect Permissions
Diagnosis:
When manually creating or copying a zone file, it’s easy to get the ownership or permissions wrong. Use ls -l as shown in Cause 2 to check ownership and permissions. The named user must be able to read (and potentially write, if dynamic updates are enabled) the zone file.
Fix:
Ensure the named user owns the file and has appropriate read permissions.
chown named:named /var/named/zones/db.example.com
chmod 644 /var/named/zones/db.example.com
If dynamic updates are used, you might need 664 or 644 depending on group membership and configuration.
Why it works: BIND runs as the named user (or a similar user). If the zone file is owned by root or another user, or if permissions prevent the named user from reading it, BIND will fail. Correcting ownership and permissions allows BIND to access the file.
Cause 4: Incorrect file Directive in named.conf
Diagnosis:
Review your named.conf (or included zone configuration files) for the specific zone causing the error.
grep "db.example.com" /etc/named.conf /etc/named/zones.conf
Look for the file directive. Ensure it points to the exact path where the zone file resides, and that there isn’t a typo or an extra directory component.
Fix:
Correct the file directive to match the actual location of the zone file.
zone "example.com" IN {
type master;
file "/var/named/zones/db.example.com"; // Ensure this path is correct
allow-transfer { 192.168.1.0/24; };
};
After editing named.conf, reload BIND.
systemctl reload named
Why it works: BIND uses the file directive to know where to find the zone data. If this path is incorrect, BIND might try to load a file from the wrong place, or it might be confused by a pre-existing file in the directory it thinks it should be looking in.
Cause 5: DNSSEC Related Issues (NSEC/NSEC3)
Diagnosis:
If DNSSEC is enabled for the zone, BIND might be generating or expecting specific files for DNSSEC records (e.g., .jnl files for RRSIG and NSEC/NSEC3 records). Check for .jnl files in the zone directory.
ls -l /var/named/zones/*.jnl
If a .jnl file exists and is not empty, but BIND is reporting the primary zone file conflict, it’s a strong indicator.
Fix:
For DNSSEC-signed zones, the journal file (.jnl) is crucial for incremental updates. If it’s corrupted or improperly handled, it can lead to this error. Often, the fix involves removing the .jnl file and allowing BIND to rebuild it.
systemctl stop named
rm /var/named/zones/db.example.com.jnl
systemctl start named
Note: This action will cause BIND to perform a full zone re-signing if keys are managed automatically. If you use manual key management, be aware of potential key rollovers.
Why it works: The .jnl file is a transaction log for changes made to a DNSSEC-signed zone. It records RRSIG, NSEC, and NSEC3 records. If this log file is present but malformed, or if BIND can’t properly reconcile it with the main zone file, it can manifest as a file conflict. Removing it allows BIND to create a fresh, correct journal.
Cause 6: SELinux Policy Issues
Diagnosis: Check SELinux audit logs for any denials related to BIND accessing its zone files.
ausearch -c named -m avc -ts recent
If you see denials like Permission denied for read or write operations on zone files, SELinux is likely the culprit.
Fix: Relabel the zone file directory or create a specific SELinux policy module. A common quick fix (though less secure than a specific policy) is to set the correct SELinux context.
chcon -R -t named_zone_t /var/named/zones/
Then, restore SELinux contexts and restart BIND.
restorecon -Rv /var/named/zones/
systemctl restart named
Why it works: SELinux enforces mandatory access controls. If the SELinux context for the zone files is incorrect, BIND might be prevented from accessing them, even if standard Unix permissions are correct, leading to unexpected behavior and errors.
The next error you might encounter after fixing this is a zone example.com/IN: zone is not loaded due to errors if there are other syntax issues within the zone file itself.