rndc: ‘reload’ failed: failure – How to Find and Fix the BIND Error in FreeBSD and Linux

Antonio NEMCD Author

Published Nov 15, 2012 · 4 min

When editing the BIND configuration on a server (for example, after adding a new zone to named.conf), trying to gently apply the changes with /etc/rc.d/named reload, service named reload, or rndc reload often ends with a terse and unhelpful error: rndc: ‘reload’ failed: failure.

When reloading BIND after editing named.conf ends with rndc: ‘reload’ failed: failure

In short: the named daemon itself usually keeps running on the old configuration, but refuses to load the new changes. To quickly pinpoint the exact line with a typo, validate the config and zone files with named-checkconf and named-checkzone, and check the system log or dmesg -a on FreeBSD for the detailed error message.

Why rndc: ‘reload’ failed: failure Happens

The rndc utility simply sends a command to the running named process and receives a generic rejection without details. Almost every time, the root cause falls into one of four scenarios:

• Syntax error in named.conf – a missing semicolon ;, an extra or unclosed curly brace }, a typo in an option name, or a duplicate declaration of the same zone.
• Typo in a zone file – a forgotten trailing dot at the end of a domain name (FQDN), an invalid Serial in the SOA record, or a CNAME record conflicting with other records on the same name.
• Dynamic zone (.jnl) – manually editing a zone file that has allow-update or update-policy enabled without freezing the journal via rndc freeze first.
• File permissions or paths – the user account running BIND cannot read the new zone file, or an include directive points to a wrong path.

Step 1. Validate named.conf and Zone File Syntax

Before guessing where a typo slipped in, the fastest approach is to run the built-in validation utilities bundled with BIND. If named-checkconf exits silently without any output, the main configuration file has no syntax errors:

# FreeBSD (BIND from ports)
named-checkconf /usr/local/etc/namedb/named.conf

# Debian / Ubuntu
named-checkconf /etc/bind/named.conf

Once the main config is clean, check the specific zone file you added or modified. At the end of a successful check, the utility outputs OK:

# FreeBSD
named-checkzone example.com /usr/local/etc/namedb/master/example.com.db

# Debian / Ubuntu
named-checkzone example.com /etc/bind/db.example.com

If there is a mistake, named-checkzone immediately prints the file name, line number, and what went wrong – such as an out-of-zone record or a duplicate entry.

Step 2. Check BIND Logs in FreeBSD and Linux

When there is an issue in named.conf or file permissions, the named daemon writes a detailed error description and line number to the system log. On classic FreeBSD setups, startup and reload messages often land right in the console buffer, so dmesg -a or searching the system log does the trick:

# Console buffer on FreeBSD
dmesg -a

# Recent named messages in the FreeBSD system log
tail -n 50 /var/log/messages | grep named

On modern Linux distributions with systemd, the easiest way to see why a reload was rejected is to inspect the service journal (on CentOS/RHEL the service is usually named named, while on Debian/Ubuntu it is bind9):

# RHEL / CentOS / AlmaLinux
journalctl -u named -n 50 --no-pager

# Debian / Ubuntu
journalctl -u bind9 -n 50 --no-pager

Step 3. Dynamic Zones and Safe Reloading

If your server uses dynamic DNS updates (allow-update or update-policy), a .jnl journal file sits next to the zone file. Editing such a zone file directly in a text editor on the fly is a bad idea – the journal will go out of sync with the text zone, and rndc reload will fail.

The proper workflow for a dynamic zone is always the same: freeze dynamic updates first, make your edits, and then thaw the zone back:

rndc freeze example.com
# edit the zone file here and increment the Serial number
rndc thaw example.com

Once all checks pass, apply the configuration again via rndc reload or your system service manager. On FreeBSD with BIND installed from ports, run service named reload (or /usr/local/etc/rc.d/named reload), and if the daemon was stopped, start it with service named restart.

Reliable Cloud VPS for Your Own DNS and Projects

If you are setting up your own authoritative DNS server, a FreeBSD/Linux lab environment, or moving away from shared hosting, it helps to run a dedicated instance with predictable networking and quick snapshots – for example, a cloud VPS at Vultr (affiliate link).

P.S. In my case on FreeBSD, the culprit turned out to be as mundane as it gets: I added a new zone to named.conf and forgot a semicolon at the end of a line. Running dmesg -a immediately pointed to the exact line with the syntax error – ever since then, I always run named-checkconf before every reload, and there are no more surprises.