BIND dynamic update failures: UpdateFail, denied updates, and TSIG drift

A rising UpdateFail counter on a BIND authoritative server means the dynamic update pipeline is broken. The counter does not tell you why. You need to correlate it with the security log, the zone serial, and the journal file state to narrow the cause.

Failures cluster into three families:

• Authentication failures: TSIG key drift, wrong key names, clock skew past the 300-second fudge window.
• Authorization failures: the zone’s allow-update or update-policy does not grant the presented key permission to modify the zone.
• Journal and filesystem failures: disk exhaustion, permission errors, .jnl corruption from manual zone edits.

Each produces a distinct signal pattern in the logs and counters. Dynamic updates are denied by default. A zone must explicitly include allow-update or update-policy to accept updates. These two directives are mutually exclusive; configuring both is a configuration error and named will refuse to load the zone.

What this means

BIND tracks dynamic update operations through NSStats counters:

All counters are cumulative since process start. A single absolute number is meaningless without computing a rate.

UpdateBadPrereq is a subset of UpdateFail. If UpdateFail rises but UpdateBadPrereq stays flat, the failures are authentication, authorization, or journal-related, not prerequisite logic in the update client. This split is the first branching point in diagnosis.

UpdateQuota was added alongside the update-quota option (default 100 concurrent updates), introduced in BIND 9.18.24 to mitigate CVE-2022-3094. A rising UpdateQuota means too many updates are in flight simultaneously, which is an overload or flood condition, not an authentication problem.

UpdateFwdFail matters when a secondary server forwards dynamic updates to a primary master using allow-update-forwarding. If updates work locally but forwarded updates fail, the problem is between this server and the upstream, not in the local zone configuration.

Common causes

Quick checks

These are safe, read-only commands. Adjust the statistics channel port, zone name, and file paths to match your deployment. Zone file paths and systemd unit names vary by distribution: RHEL-family uses /var/named/ and the named unit; Debian-family uses /var/cache/bind/ or /var/lib/bind/ and the bind9 unit.

# Check all update-related counters
# <!-- TODO: verify JSON structure for your BIND version; nsstats may be a
# list of {"name":..., "value":...} objects rather than a dict -->
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
  [print(f\"{x['name']}: {x['value']}\") for x in d.get('nsstats',[]) \
  if x['name'].startswith('Update')]"

# Check zone serial (should advance after successful updates)
dig +norecurse @127.0.0.1 example.com SOA +short | awk '{print $3}'

# Check journal file existence, age, and size
ls -la /var/named/example.com.jnl 2>/dev/null || echo "NO JOURNAL FILE"

# Check update-related security log entries (use bind9 on Debian/Ubuntu)
journalctl -u named --since "30 min ago" | grep -iE "update|denied|tsig|badkey|badsig|badtime"

# Check disk space on the partition holding zone files
df -h /var/named

# Check directory permissions for the named user
ls -ld /var/named

# Verify update configuration in the parsed config
named-checkconf -p /etc/named.conf | grep -A5 -iE "allow-update|update-policy"

# Check NTP sync (critical for TSIG BADTIME diagnosis)
chronyc tracking 2>/dev/null || timedatectl status

# Check update-quota setting
named-checkconf -p /etc/named.conf | grep -i "update-quota"

How to diagnose it

The diagnostic flow branches early based on what the security log shows. TSIG errors point to key or clock problems. Denial logs without TSIG errors point to authorization gaps. SERVFAIL without denial logs points to journal or filesystem problems.

flowchart TD
    A["UpdateFail rising"] --> B{"TSIG error
in security log?"}
    B -- "BADKEY" --> C["Key name in nsupdate
does not match named.conf"]
    B -- "BADSIG" --> D["Shared secret differs
between client and server"]
    B -- "BADTIME" --> E["Clock skew exceeds
300s fudge factor"]
    B -- "No TSIG error" --> F{"Log shows
update denied?"}
    F -- "With signer" --> G["Key recognized but
update-policy excludes it"]
    F -- "Without signer" --> H["allow-update or
update-policy not set"]
    F -- "No denial log" --> I["Journal or disk failure
check .jnl and permissions"]

1. Confirm the counter is actually rising. Sample twice with a known interval and compute the delta. BIND counters are cumulative since startup, so a static high number from hours ago is not an active problem.

2. Check whether UpdateBadPrereq is also rising. If it is, the problem is in the update client’s prerequisite logic, not in authentication or authorization. The nsupdate script is sending prerequisites that do not match the current zone state.

3. Grep the security log for TSIG errors. The three standard TSIG failure codes are BADKEY (key name not recognized), BADSIG (signature verification failed, meaning the shared secret differs), and BADTIME (timestamp outside the 300-second fudge window). Each points to a different fix.

4. If you see “update denied” with a signer line, the TSIG key was recognized but the zone’s allow-update or update-policy does not grant it permission. Check that the key name in the policy matches the key statement.

5. If you see “update denied” without a signer, the update arrived without TSIG authentication. Either the client is not signing updates at all, or the zone has no allow-update or update-policy configured.

6. If updates return SERVFAIL with no denial log, check the journal file and filesystem. The .jnl file may be corrupt (common after manual zone file edits), the disk may be full, or named may lack write permission on the zone directory.

7. Check UpdateQuota alongside UpdateFail. If UpdateQuota is also rising, the server is rejecting updates due to concurrent update volume exceeding update-quota (default 100). This is an overload condition, not a configuration error.

Metrics and signals to monitor

Fixes

TSIG key name mismatch (BADKEY)

The key name in the nsupdate command must match the key name in the named.conf key statement exactly. A common mistake is using the algorithm name, the zone name, or a truncated version of the key identifier instead of the actual key name.

Verify the key name on the server:

named-checkconf -p /etc/named.conf | grep -A3 "key "

Then confirm the nsupdate client uses the same name. If you are using a key file generated by tsig-keygen or ddns-confgen, the file contains the key name in its header.

TSIG shared secret drift (BADSIG)

The shared secret differs between client and server. This happens after key regeneration on one side without redistributing to the other. Regenerate the key, distribute it to both sides, and reload named.

If you use update-policy local, BIND generates a session key automatically with key name local-ddns and algorithm HMAC-SHA256. The nsupdate -l flag uses this session key. If the session key file is missing or stale (for example, after a partial restart or filesystem issue), local updates fail with BADSIG.

Clock skew (BADTIME)

The TSIG fudge factor is 300 seconds by default. Clock skew beyond this window produces BADTIME. Run NTP or chrony on both the update client and the BIND server. Check synchronisation:

# On both client and server
chronyc tracking 2>/dev/null || timedatectl status

If the clock was recently corrected, updates should resume immediately. No named restart is needed.

Authorization gap (denied with signer)

The TSIG key authenticates correctly, but the zone’s allow-update or update-policy does not grant that key permission. Verify the configuration:

named-checkconf -p /etc/named.conf | grep -B2 -A10 "allow-update\|update-policy"

For allow-update, the key or ACL must include the update source. For update-policy, the rule must match the key name, the zone, and the record types being updated. A rule that grants updates for A records will reject TXT record updates, for example.

No update policy configured (denied without signer)

If the zone has neither allow-update nor update-policy, all dynamic updates are denied by default. This is correct behavior for a static zone that should not receive dynamic updates. If updates are expected, add the appropriate directive.

Journal corruption

If a zone file is manually edited while dynamic updates are active, the .jnl file goes out of sync with the zone file. BIND may refuse further updates or fail to load the zone on restart.

The safe edit procedure for dynamic zones is to freeze, edit, and thaw:

# CAUTION: rndc freeze stops dynamic updates for the zone
rndc freeze example.com
# Edit the zone file here
named-checkzone example.com /var/named/example.com.zone
rndc thaw example.com

If the journal is already corrupt, recovery requires removing the .jnl file. This is destructive: any updates stored only in the journal (not yet written to the zone file) are lost. The preferred method is rndc sync -clean, which syncs the journal to the zone file first, then removes the journal:

# Preferred: sync then clean
rndc sync -clean example.com

# DESTRUCTIVE alternative if rndc sync fails: stops updates, removes journal,
# loses any uncommitted updates
rndc freeze example.com
rm /var/named/example.com.jnl
rndc thaw example.com

After removing the journal, named reloads the zone from the static file. Future updates create a new journal.

Disk full or permissions

If named cannot write to the zone directory, updates fail with SERVFAIL. Check disk space and directory ownership. On systems with AppArmor or SELinux, named may be prevented from writing outside its configured directory. On Ubuntu, /var/lib/bind/ is the conventional location for dynamically updated zones.

Update-quota exhaustion

If UpdateQuota is rising, the server is rejecting updates because concurrent in-flight updates exceed update-quota (default 100). Investigate whether the update client is sending updates faster than named can process them. You can raise update-quota in named.conf, but first determine whether the volume is legitimate or a malfunctioning client.

Prevention

• Version-control TSIG keys. Track key creation, rotation, and distribution. Key drift between client and server is the most common UpdateFail cause.
• Run NTP on all update clients. Clock skew is silent until it crosses the 300-second fudge window, then every update fails.
• Validate configuration before reload. Run named-checkconf and named-checkzone before any rndc reload. A syntax error in one zone does not block others from loading, but the failed zone silently stops accepting updates.
• Never manually edit dynamic zone files without freezing first. Unfreezed edits corrupt the journal.
• Monitor Update counters as rates, not absolutes.* Cumulative counters since startup hide active problems behind historical accumulation.
• Alert on UpdateQuota. This counter is zero in normal operation. Any non-zero rate means the server is overloaded by update volume.
• Track zone serial changes. If updates are expected on a schedule but the serial stops advancing, something is failing silently.

How Netdata helps

• Netdata collects all NSStats Update* counters per second, so you see UpdateFail rate changes immediately rather than discovering them from a stale cumulative snapshot.
• Correlating UpdateFail with UpdateBadPrereq distinguishes client prerequisite errors from authentication or authorization failures without manual delta computation.
• Anomaly detection on UpdateFail rate catches subtle increases that a fixed threshold would miss, especially in environments where update volume varies by time of day.
• The security log and BIND statistics are collected together, so TSIG error patterns align with counter shifts without manual cross-referencing.

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