BIND is refusing to answer queries for a zone because it believes it doesn’t have the correct, up-to-date information to be considered authoritative. This usually means its zone data is either missing, corrupted, or it’s simply not configured to serve it.
The most common culprit is a simple typo in the zone definition within named.conf. BIND is case-sensitive and whitespace-sensitive. A stray space before or after the zone name, or a capitalization mismatch, will cause BIND to ignore the zone entirely.
sudo grep -i "your.zone.name" /etc/named.conf /etc/named.conf.d/*
Fix: Carefully inspect your named.conf and any included files for the exact zone name. Ensure it matches precisely, including case and the absence of leading/trailing whitespace. For example, if your zone is example.com, it should appear as zone "example.com" { ... }; and not zone " example.com" { ... }; or zone "Example.com" { ... };. Restart BIND after correction: sudo systemctl restart named.
Next, check if the zone file itself is actually present and readable by the BIND process. If the zone file is missing or has incorrect permissions, BIND can’t load it.
ls -l /var/named/your.zone.name.db
Fix: Verify the zone file exists at the path specified in named.conf. Ensure the file permissions allow the named user (often named or bind) to read it. For example: sudo chown named:named /var/named/example.com.db and sudo chmod 644 /var/named/example.com.db. Then, check BIND’s logs for specific file loading errors: sudo journalctl -u named -f.
A corrupt zone file, often due to incomplete transfers or manual editing errors, will prevent BIND from parsing it. This can manifest as a "not authoritative" error if BIND fails to load the file during startup or reload.
sudo named-checkzone your.zone.name /var/named/your.zone.name.db
Fix: Run named-checkzone on your zone file. It will report syntax errors. Common issues include missing closing semicolons, incorrect record types, or invalid IP addresses. Correct the syntax errors reported by named-checkzone and reload BIND: sudo rndc reload your.zone.name.
If you’re running BIND as a slave server, the zone transfer from the master might have failed, leaving the slave with an old or empty zone file.
sudo rndc zonestatus your.zone.name
Fix: On the slave server, check the zonestatus output for the serial number. If it’s old or 0, the transfer likely failed. Check the master server’s logs for AXFR/IXFR denial or errors. On the slave, you can force a re-transfer with sudo rndc retransfer your.zone.name. Ensure the master allows zone transfers (allow-transfer) to the slave’s IP address.
BIND’s configuration might explicitly deny serving the zone, even if it’s present. This is often a security measure.
sudo grep -i "allow-query" /etc/named.conf /etc/named.conf.d/*
sudo grep -i "allow-transfer" /etc/named.conf /etc/named.conf.d/*
Fix: Examine the allow-query and allow-transfer directives within your zone definition in named.conf. If the IP address of the client making the query (or the slave server asking for a transfer) is not explicitly listed or covered by a broader ACL, BIND will deny the request. Add the necessary IP addresses or ACLs. For example: allow-query { localhost; 192.168.1.0/24; };.
A more subtle issue is when BIND has a stale cache entry for the zone’s SOA record. Even if the zone data is corrected, BIND might still be referencing an old SOA that indicates it’s not authoritative.
dig soa your.zone.name @localhost
Fix: If the SOA serial number returned by dig is old, it might indicate a caching issue or that BIND hasn’t fully reloaded. Try clearing BIND’s cache with sudo rndc flushname your.zone.name and then reload BIND entirely (sudo systemctl restart named).
The next error you’ll likely encounter is a SERVFAIL response if BIND is still unable to resolve queries due to a different underlying issue, such as network connectivity problems to upstream DNS servers.