Troubleshooting: bind9 Not Starting on Kali Linux

The bind9 service failing to start on Kali Linux is typically caused by syntax errors in configuration files, incorrect file permissions, or port conflicts. By checking the systemd logs, validating the zone files with named-checkconf, and ensuring the correct ownership for dynamic directories like /var/cache/bind, you can resolve most startup failures without compromising system security.

Identifying the Root Cause

When a service fails to initialize during boot or manual invocation, the first step is to determine exactly why the process exited. In Kali Linux, which uses systemd as its init system, all service statuses are managed through the systemctl command. You should not guess the cause; instead, you must look at the specific error codes returned by the daemon. Run the following command to check the current status of the BIND 9 server:

sudo systemctl status bind9

If the service is inactive or failed, the output will show red text indicating the failure reason. More importantly, you need to see the exit code or the specific log message that triggered the stop. Often, the systemctl status output provides a brief summary, but it may truncate detailed error messages. For a complete view, you should query the journal daemon directly. This allows you to see the full stack trace of what happened right before the service died. Use this command to retrieve the most recent logs related to bind9:

sudo journalctl -u bind9 -n 50 --no-pager

This approach isolates the problem from other system noise. You might see errors such as "permission denied," "zone file not found," or "address already in use." Each of these symptoms points to a different underlying issue, ranging from security restrictions to network configuration mistakes. Understanding the exact error message prevents you from applying random fixes that do not address the core problem.

Validating Configuration Syntax

One of the most common reasons for bind9 failing to start is a typo or syntax error in the main configuration file or one of the included zone files. BIND is extremely strict about its configuration language. Even a missing semicolon or an unclosed brace can prevent the entire daemon from launching. Before restarting the service, you should always validate the configuration files using the built-in diagnostic tools provided by the package. The primary tool for this task is named-checkconf. This utility reads the main configuration file, usually located at /etc/bind/named.conf, and checks for structural correctness. It does not check the actual data in your zones, but it ensures that the directives are valid and that the file paths referenced in the configuration actually exist. Run the validation command as follows:

sudo named-checkconf

If the command returns no output, it means the configuration syntax is valid. If it outputs an error, it will tell you the line number and the nature of the mistake. Fix the indicated error in /etc/bind/named.conf.local or /etc/bind/named.conf.default-zones and run the check again until it passes silently. After confirming the main configuration is valid, you should also check the individual zone files. Use named-checkzone to verify the integrity of your DNS records. The syntax for this command requires the zone name and the path to the zone file. For example:

sudo named-checkzone example.com /etc/bind/db.example.com

If there are errors in the zone file, such as invalid IP addresses or missing SOA records, they will be reported here. Correcting these issues ensures that once the service starts, it can actually serve the requested domains. Skipping this step often leads to services starting successfully but then crashing immediately when they attempt to load the faulty zone data.

Checking File Permissions and Ownership

Security-conscious distributions like Kali Linux enforce strict permission models. If the BIND daemon cannot read its configuration files or write to its cache directories, it will refuse to start. However, you must be careful not to apply overly broad permissions that could compromise system security. A common mistake is changing the ownership of the entire /etc/bind directory to the bind user. This is dangerous because it allows the unprivileged service account to modify configuration files, potentially leading to privilege escalation attacks. The correct approach is to ensure that the root user owns the configuration files, while the bind user has read access. The dynamic directories, such as those used for caching or writing update files, must be owned by the bind user so the daemon can write to them. First, verify the ownership of the main configuration directory:

ls -l /etc/bind/

All files in /etc/bind should be owned by root:root. If you see bind:bind or other users, change them back to root:

sudo chown root:root /etc/bind/*

Next, check the cache and dump directories. These are typically located in /var/cache/bind and /var/run/bind/run. The bind user needs write access to these locations. You can fix the permissions on the cache directory specifically:

sudo chown -R bind:bind /var/cache/bind

Do not change the ownership of /etc/bind recursively to bind. This was a critical error in previous troubleshooting guides and creates a significant security vulnerability. Keeping configuration files root-owned ensures that only administrators can change how the DNS server behaves.

Resolving Port Conflicts

Sometimes, the configuration is perfect, the permissions are correct, and the syntax is valid, yet bind9 still fails to start. In these cases, the issue is often that another process is already listening on port 53, which is the standard port for DNS traffic. Kali Linux systems may have other lightweight DNS resolvers or proxies installed that conflict with the full-featured BIND daemon. You can check if port 53 is in use by any other process using the ss or netstat commands. Run the following to list all processes listening on UDP port 53:

sudo ss -ulnp | grep :53

If you see a result other than named (the binary for bind9), you have a conflict. Common culprits include dnsmasq or systemd-resolved. If systemd-resolved is active, it often binds to port 53 locally. You can disable this conflict by stopping and disabling the conflicting service, or by configuring BIND to listen on a different interface. For most Kali Linux installations, disabling systemd-resolved is unnecessary if you configure BIND correctly. Instead, ensure that BIND is configured to listen only on the interfaces you intend to serve. Check the listen-on directive in your named.conf.options file. If it is set to any, it might conflict with local loopback resolvers. Setting it to specific IPs or localhost can help avoid collisions.

Restarting and Verifying the Service

Once you have addressed syntax errors, validated zone files, corrected permissions, and resolved port conflicts, you are ready to restart the service. Always reload the systemd manager to pick up any changes in unit files or dependencies before starting the service again. Execute the following commands in sequence:

sudo systemctl daemon-reload
sudo systemctl restart bind9
sudo systemctl enable bind9

The enable command ensures that bind9 starts automatically on boot. After running restart, immediately check the status again:

sudo systemctl status bind9

Look for the green "active (running)" indicator. If it is still failing, return to the journal logs with journalctl -u bind9 -f to watch real-time output. This final verification step confirms that your troubleshooting efforts were successful and that the DNS server is operational.

Frequently Asked Questions

Why does bind9 fail with a permission denied error?

This usually happens when the bind user cannot read the configuration files in /etc/bind or write to the cache directory. Ensure config files are owned by root and cache directories are owned by the bind user.

Can I use dnsmasq instead of bind9 on Kali Linux?

Yes, dnsmasq is lighter and easier to configure for simple setups. However, bind9 is required for complex enterprise DNS features like split-horizon views and advanced ACLs. Choose based on your complexity needs.

How do I check if another service is using port 53?

Use the command sudo ss -ulnp | grep :53 to see which process holds the port. If systemd-resolved is blocking it, you may need to adjust its configuration or disable it for local resolution.

What is the difference between named-checkconf and named-checkzone?

named-checkconf validates the syntax of the main configuration file, while named-checkzone validates the data records within a specific zone file. Both should pass before starting the service.

Is it safe to change /etc/bind ownership to bind?

No, it is not safe. Changing /etc/bind to be owned by the bind user allows the unprivileged service to modify its own configuration, which is a security risk. Keep these files owned by root.