Verifying rndc reload: catching a failed zone load before your clients do

rndc reload queues a zone reload and returns immediately with a success message. It does not confirm that the zone actually loaded. If the zone file has a syntax error, a missing include, or a permission problem, the error goes into the BIND log and nowhere else. The operator sees success. The zone is either stale (on reload failure, BIND continues serving the previous version) or answering SERVFAIL/REFUSED (on restart or initial load failure).

named keeps running. Other zones keep answering. Process health checks stay green. rndc status shows the daemon is up. The first sign of trouble is a user complaint or a monitoring alert on one specific zone.

The fix is operational discipline: validate before you reload, then verify after.

Why this matters

A failed zone load is a silent failure. named continues running and serves everything else normally while the affected zone is either stale or broken.

During a reload, BIND keeps the previous zone data in memory while it validates and loads the new version from disk. If the load fails, the old data continues to be served. The risk is not an immediate outage but undetected staleness: operators believe their change is live when the old serial is still answering. On a full restart, the same bad zone file produces a harder failure: the zone is unavailable and clients see REFUSED or SERVFAIL.

Prerequisites

• Working rndc control channel: rndc status must return immediately with the BIND version line. If rndc is unresponsive, fix that first.
• Read access to zone files and named.conf: typically /etc/named.conf and /var/named/ or /etc/bind/, depending on distribution.
• bind9-utils installed: provides named-checkconf, named-checkzone, and rndc.
• Knowledge of which zones you are changing: targeted reloads are safer than full reloads.

Procedure

Three phases: pre-reload validation, the reload itself, and post-reload verification.

flowchart TD
    A[Edit zone file] --> B[named-checkconf -zj]
    B -->|fail| C[Fix config error]
    C --> B
    B -->|pass| D[named-checkzone]
    D -->|fail| E[Fix zone syntax]
    E --> D
    D -->|pass| F[rndc reload zone]
    F --> G[rndc zonestatus zone]
    G --> H{Serial matches?}
    H -->|yes| I[Log confirms load]
    H -->|not yet| G
    I --> J[dig SOA functional check]
    J -->|correct answer| K[Zone verified live]
    J -->|SERVFAIL or wrong| L[Check log, fix, retry]
    L --> A

Phase 1: pre-reload validation

Validate the full configuration with a test load:

named-checkconf -zj /etc/named.conf

The -z flag performs a test load of all primary zones found in named.conf. The -j flag reads journal files during the check. Exit code 0 means success; 1 means error. If this fails, fix the error before reloading.

Validate the specific zone file you are changing:

named-checkzone example.com /var/named/zones/example.com.zone

This catches the most common zone file errors: missing trailing dots on FQDNs, malformed records, duplicate records, invalid TTLs.

Phase 2: execute the reload

Reload the specific zone, not all zones:

rndc reload example.com

A bare rndc reload reloads the configuration file and every zone on the server. On a busy authoritative server with many zones, this is expensive and unnecessary for a single-zone change.

For zones served in multiple views, specify the view explicitly:

rndc reload example.com IN external

Without the view qualifier, the reload may target the wrong zone instance or fail silently.

Do not confuse rndc reload with rndc reconfig. rndc reconfig reloads named.conf and loads any newly added zones, but does not reload existing zone file data. Use rndc reconfig when you have added or removed zone stanzas. Use rndc reload <zone> when you have changed zone file contents on disk.

Phase 3: post-reload verification

Confirm the zone count:

rndc status | grep -i "zones"

Compare against your expected baseline. A missing zone means a load failure. Note that rndc status includes internal zones (such as bind/CH and the hint zone) in the count.

Confirm the zone serial:

rndc zonestatus example.com

This shows the current serial, master file name, last load time, and whether the zone supports dynamic updates or inline signing. Compare the serial against the one in your zone file. If it has not changed, one of three things happened:

• The reload is still in progress (large zones take longer to validate and load).
• The load failed (check the log).
• The zone file was not actually modified on disk before the reload was issued.

Check the BIND log for confirmation or errors:

# Service name may be 'bind9' instead of 'named' on Debian/Ubuntu
journalctl -u named --since "5 min ago" | grep -i "zone.*loaded\|zone.*failed\|not loaded\|loading from master file"

A successful load produces a message like zone example.com/IN: loaded serial 2026072201. A failure produces zone example.com/IN: loading from master file ... failed followed by the specific error.

Functional verification with a direct query:

# Authoritative: query the zone directly with recursion disabled
dig +norecurse +time=2 +tries=1 @127.0.0.1 example.com SOA +short
# Verify the serial in the SOA response matches your expected value

# Recursive with local zones: standard query
dig +time=2 +tries=1 @127.0.0.1 www.example.com A +short

For authoritative servers, use +norecurse to query the local zone data directly. Verify the SOA serial in the response.

Probe from a client perspective:

dig +time=2 +tries=1 @<server-ip> example.com SOA +short

BIND views can cause a zone to load correctly from localhost but fail from a client subnet. Test from the same network path your clients use.

Verifying it works

Verification is complete when all of the following are true:

• named-checkconf -zj passed: exit code 0, no errors printed.
• named-checkzone passed: exit code 0, no errors printed.
• rndc zonestatus shows the expected serial.
• BIND log confirms the load: a zone ... loaded serial ... message appears after the reload.
• Functional dig returns the correct answer from both localhost and a client-perspective probe.

If any of these fail, the zone is not serving the new data. Check the BIND log for the specific error, fix the zone file or configuration, and repeat from phase 1.

Common pitfalls

Dynamic zones do not need rndc reload. Current BIND treats a dynamic zone as already loaded when rndc reload is issued (DNS_R_DYNAMIC is accepted as success). To edit its master file safely, use the freeze/thaw cycle:

# Freeze the zone (stops dynamic updates, writes journal to zone file)
rndc freeze example.com
# Edit the zone file on disk
# Thaw the zone (resumes dynamic updates, reloads the zone)
rndc thaw example.com

Journal corruption blocks zone loads. A valid zone file can still fail to load if the journal file (.jnl) is corrupted. The zone file passes named-checkzone, but the journal replay fails during load. To recover:

# WARNING: writes journal to zone file and DELETES the journal.
# Any dynamic updates in the journal that cannot be replayed will be lost.
rndc sync -clean example.com
rndc reload example.com

Use this only when the journal is corrupted and the zone will not load.

Large zones and timing. Zone validation on load takes longer for zones with many records. During this period, BIND continues serving the previous version. Do not interpret a delay in the serial update as a failure. Wait, then re-check rndc zonestatus.

named-checkconf has limits. It validates named.conf and all files included by it, but does not automatically read separately parsed files such as rndc.conf or rndc.key; check those explicitly. It also cannot catch every permission or runtime-path condition encountered by the running named process. A passing named-checkconf reduces reload risk but does not guarantee a clean full restart.

Multiple views without view specification. In multi-view configurations, rndc reload example.com without specifying the view may target the wrong view or fail. Always use rndc reload <zone> IN <view>.

Signals to monitor

How Netdata helps

Netdata’s BIND collector surfaces signals that matter for reload verification:

• QrySERVFAIL counter (NSStats): per-second granularity lets you correlate a SERVFAIL spike with the exact moment of your reload event.
• Response code distribution: shifts in NOERROR, NXDOMAIN, SERVFAIL, and REFUSED ratios after a reload immediately reveal whether the new data is serving correctly.
• Zone serial mismatch: for authoritative servers with secondaries, compare primary and secondary serials after a reload to confirm that zone transfers are propagating the new data; use rndc zonestatus on each server unless your monitoring layer already exposes per-zone serials.

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