BIND zone not loaded after reload: 'loading from master file failed' and the silent zone outage

You ran rndc reload after editing a zone file. rndc status reports the server is running. systemd says the service is active. Your monitoring confirms the process is alive and port 53 is open. But something is wrong with one specific zone.

named does not crash when a single zone fails to load. It logs the error and continues serving the zones that loaded successfully. Two outcomes are possible for the affected zone:

• Stale data (reload failure): If the zone was already loaded, the old version stays in memory. Queries still return NOERROR, but with the pre-edit serial. Your changes are not live and nothing alerts you.
• Dark zone (restart or first load): If the zone was never loaded (broken file at startup, or a new zone that failed), it is absent from memory. Queries return REFUSED or SERVFAIL.

The stale-data case is the harder one to catch. rndc reload returns success when named accepts the command, not when every zone loads. rndc zonestatus shows a serial number, but it is the old one. Process-level and port-level checks pass. Only log analysis and serial verification catch it.

What this means

When named processes rndc reload, it re-reads zone files one at a time. For each zone, it parses the file, validates the records, and attempts to load the data into its in-memory zone database. If parsing fails for a specific zone, named logs the error and preserves the existing in-memory data for that zone. The daemon stays running.

After a full restart (systemctl restart named), there is no existing in-memory data to fall back on. A zone that fails to load at startup is simply absent. Queries for names in that zone receive REFUSED (the server does not consider itself authoritative) or SERVFAIL (a DNSSEC signing or journal error left the zone in an inconsistent state).

This distinction matters for detection: after rndc reload, the failed zone still answers queries with stale data. After a restart, it goes dark.

flowchart TD
    A["rndc reload or restart"] --> B["named parses each zone file"]
    B -->|"syntax OK"| C["Load zone into memory"]
    B -->|"parse error"| D["Log: loading from master file failed"]
    C --> E["Log: loaded serial N"]
    D --> F{"Zone already in memory?"}
    F -->|"Yes, reload case"| G["Old data persists, stale serial"]
    F -->|"No, restart or new"| H["Zone absent from memory"]
    E --> I["Queries: NOERROR, current serial"]
    G --> J["Queries: NOERROR, stale serial"]
    H --> K["Queries: REFUSED or SERVFAIL"]
    I --> L["named continues running"]
    J --> L
    K --> L

Process liveness tells you nothing about zone-level health. A health check that probes a single zone or checks pgrep named will not detect this failure. You need per-zone verification.

Common causes

Quick checks

All of these are safe, read-only operations.

# Check daemon responsiveness and basic state
rndc status

# Check the specific zone's loaded state (serial, master file path)
rndc zonestatus example.com

# Scan recent logs for zone load failures
# NOTE: on Debian/Ubuntu the unit is named 'bind9', not 'named'
journalctl -u named --since "5 min ago" | grep -i "zone.*loaded\|zone.*failed\|not loaded"

# Validate the zone file before attempting another reload
named-checkzone example.com /var/named/example.com.zone

# Validate the full named.conf
named-checkconf /etc/named.conf

# Test the zone directly (authoritative probe, no recursion)
dig +time=2 +tries=1 +norecurse @127.0.0.1 example.com SOA

For a successfully loaded zone, rndc zonestatus shows a serial number and the master file path. After a failed reload of a previously loaded zone, it still shows a serial, but it is the old one. Compare it against the serial in the zone file on disk.

How to diagnose it

1. Check the logs first. The error message from named identifies the zone and the specific failure. Look for: zone example.com/IN: loading from master file <path> failed, followed by the underlying cause. Compare against the success pattern: zone example.com/IN: loaded serial N.

2. Run named-checkzone on the zone file. This reproduces the same validation that named performs at load time. It catches syntax errors, CNAME conflicts, missing trailing dots, and malformed records. The exit code is non-zero on failure.

3. Check the zone file path in named.conf. If the path is wrong, named logs a file-not-found error. Pay special attention to chroot deployments: if named runs in a chroot, the path in named.conf is relative to the chroot root, not the filesystem root.

4. Check for journal corruption. If the zone uses dynamic updates (DDNS) or inline signing, a .jnl file exists alongside the zone file. If the zone file was manually edited while the journal existed, the journal is now out of sync. The log will show “journal rollforward failed: journal out of sync with zone.”

5. Check file permissions. The named process must have read access to the zone file. After copying files between hosts or changing ownership, the named user may no longer be able to read the file. For dynamic zones, named also needs write access to both the zone file and the .jnl.

6. Check DNSSEC state for signed zones. Verify that key files exist and are accessible. Run rndc signing -list <zone> to see the signing state. Missing key files can cause a zone to fail loading or to load unsigned silently without an explicit error in the log.

Metrics and signals to monitor

Fixes

Zone-file syntax errors

Fix the syntax error identified by named-checkzone, then reload the specific zone:

# Validate first
named-checkzone example.com /var/named/example.com.zone

# Fix reported errors, then reload just that zone
rndc reload example.com

Common syntax errors include a name that has both a CNAME and another record type at the same owner name, missing trailing dots on FQDNs, and malformed record syntax. named-checkzone reports the specific line and error for each issue.

Missing zone file

Verify the file directive in the zone stanza of named.conf points to the correct path. In chroot deployments, the path is relative to the chroot root. Test with named-checkconf -z to verify all configured zone files are readable without sending a reload to the running daemon.

Journal corruption

If the zone file was manually edited while a .jnl file existed from dynamic updates, the journal is out of sync with the zone file and BIND cannot replay it.

Do not use rndc sync -clean blindly in this scenario. rndc sync writes the current in-memory zone data back to the zone file on disk. If the reload already failed, the in-memory data is the old pre-edit version, and rndc sync -clean would overwrite your manual edits with stale data.

Safe recovery when the journal is out of sync after manual editing:

# WARNING: this stops the DNS server. Plan for brief unavailability
# of all zones on this server.
systemctl stop named

# Remove the stale journal so BIND does not try to replay it
rm /var/named/example.com.zone.jnl

# Verify the zone file has your intended edits and validates
named-checkzone example.com /var/named/example.com.zone

# Start named; the zone loads from the edited file with no journal to replay
systemctl start named

For future edits to dynamic zones, use the freeze/thaw workflow to avoid journal conflicts:

# Freeze: stop dynamic updates and sync the journal to the zone file
rndc freeze example.com

# Edit the zone file safely

# Thaw: resume dynamic updates
rndc thaw example.com

Permissions

# Check ownership and permissions
ls -la /var/named/example.com.zone

# Fix ownership (adjust user and group for your distribution)
chown named:named /var/named/example.com.zone
chmod 640 /var/named/example.com.zone

# Reload the zone
rndc reload example.com

In chroot deployments, also verify the file is visible inside the chroot jail, not just on the host filesystem.

DNSSEC key issues

For inline-signed zones, verify key files exist and are readable:

rndc signing -list example.com
ls -la /var/named/Kexample.com.*

Missing key files can produce no explicit log error. The zone may load unsigned or fail to load entirely, depending on the signing configuration. On BIND 9.20, all DNSSEC-signed zones using dnssec-policy become inline-signed by default unless explicitly set to inline-signing no. This creates .signed.jnl files alongside zone files, which can cause confusion if operators are unaware of the change.

New zone not recognized after reload

If you added a new zone stanza to an included file and ran rndc reload, the zone will not be loaded. rndc reload re-reads zone data for already-configured zones only. To pick up new zone stanzas, re-read the full configuration:

rndc reconfig

Then verify the new zone loaded with rndc zonestatus.

Prevention

Run named-checkzone before every reload. Validate each zone file before sending rndc reload. This catches syntax errors before they reach the running server and is the single most effective preventive measure.

Run named-checkconf before every reload. Validate the full configuration, including zone stanzas and file paths, to catch structural errors.

Verify every zone after reload. After rndc reload, check that each zone loaded successfully. At minimum, grep the logs for “loaded serial” and “failed” or “not loaded.” For production zones, run a functional probe against each one using dig +norecurse and compare the returned serial against the zone file.

Use freeze/thaw for dynamic zones. Never edit a dynamic zone file directly. Use rndc freeze before editing and rndc thaw after. This syncs the journal, prevents corruption, and is the standard workflow for maintaining DDNS-enabled zones.

Add named-checkzone to CI or pre-deploy hooks. If zone files are generated or deployed by automation, add a validation step that runs named-checkzone before the file reaches the server.

Beware named-compilezone on BIND 9.20. named-compilezone no longer performs zone integrity checks by default in BIND 9.20. If your deployment pipeline relied on named-compilezone for validation, it will silently pass files that named-checkzone would reject. Run named-checkzone explicitly.

Use per-zone functional monitoring. The most effective detection for this failure pattern is a periodic canary query against each production zone’s SOA record. Alert on REFUSED, SERVFAIL, timeout, or a serial that does not match the expected value. Process-liveness and port-open checks will not detect a zone that failed to load or is serving stale data.

How Netdata helps

Netdata’s BIND collector reads the statistics channel at per-second resolution. For this failure pattern:

• Response code distribution shows a step increase in SERVFAIL or REFUSED when a zone goes dark after a failed restart. On a high-traffic server, a single failed zone may produce a small but sharp spike relative to total query volume.
• On a failed reload where the zone serves stale data, response codes look normal. The signal is the absence of a serial change in the zone transfer or SOA-query metrics after a known reload event.
• Correlating response code changes with named process events (restarts, reloads) helps distinguish a zone load failure from an upstream resolution problem.
• On secondary servers, zone transfer and serial consistency metrics help distinguish a primary-side load failure from a transfer failure on the secondary.
• The anomaly advisor may flag the response code shift as anomalous even when the absolute SERVFAIL count is low relative to total traffic.

Related guides

• BIND cache eviction storms: DeleteLRU, an undersized max-cache-size, and the pressure spiral
• BIND cache hit ratio dropping: the leading edge of recursive pain
• BIND clients-per-query and max-clients-per-query: duplicate recursion for popular names
• BIND cold cache after restart: the warming storm and elevated upstream load
• BIND forwarding loops: recursion that never terminates and burns recursive slots
• How BIND actually works in production: a mental model for operators
• BIND lame delegations: ’lame server resolving’ and nameservers that are not authoritative
• BIND max-cache-size: sizing the resolver cache without triggering the OOM killer
• BIND monitoring checklist: the signals every production resolver and authoritative server needs
• BIND monitoring maturity model: from survival to expert
• BIND ’no more recursive clients: quota reached’: the recursive-clients circuit breaker
• named not responding on port 53: total outage versus UDP-works-TCP-fails