BIND TSIG failure on zone transfer: BADKEY, BADTIME, and refused transfers

Zone transfers between your BIND primary and secondary have stopped. The secondary is falling behind on SOA serial, and the logs show TSIG verification failures: BADKEY, BADTIME, or BADSIG. The transfer is refused, and the secondary silently drifts toward zone expiry.

The failure hides in the security and xfer-in logging categories, not in the main query path. A secondary can serve stale data for days or weeks until the SOA expire timer runs out, at which point it stops serving the zone entirely and returns SERVFAIL. Nothing alerts until the zone disappears.

This article covers how to distinguish TSIG failures from ACL refusals and network issues, how to reconcile keys and clocks, and how to monitor the signals that give early warning.

How TSIG validation works

TSIG (Transaction SIGnature) is a shared-secret HMAC authentication mechanism defined in RFC 2845. It signs zone transfer requests (AXFR/IXFR), NOTIFY messages, and dynamic DNS updates. The sender computes an HMAC over the DNS message using a key that both sides share and includes a timestamp. The receiver recomputes the HMAC, compares, and checks the timestamp against its own clock within a configurable fudge factor.

When validation fails, BIND returns a TSIG extended error code:

• BADKEY: The key name or algorithm in the request does not match any key the receiver has configured. Usually caused by one-sided key rotation or a key name string that does not match exactly between primary and secondary configurations.
• BADTIME: The key is recognized, but the timestamp differs from the receiver’s clock by more than the fudge factor (default 300 seconds). This ties zone transfer health to NTP synchronization, just as DNSSEC validation depends on accurate time.
• BADSIG: The key is recognized and the timestamp is within fudge, but the HMAC does not verify. Usually indicates a corrupted key secret or an algorithm mismatch.

A TSIG failure is not the same as a transfer refused by an ACL. Both produce a REFUSED rcode at the DNS level, but the TSIG error code in the response distinguishes them. You need the xfer-in and security log categories to see which one is happening.

flowchart TD
    A["Transfer refused"] --> B{"TSIG error in logs?"}
    B -- "Yes" --> C{"Which error code?"}
    B -- "No" --> D["Check allow-transfer ACL
and TCP/53 connectivity"]
    C -- "BADKEY" --> E["Key name mismatch or
one-sided rotation"]
    C -- "BADTIME" --> F["Clock skew beyond fudge"]
    C -- "BADSIG" --> G["Algorithm mismatch or
corrupted secret"]
    E --> H["Reconcile key definitions
on both servers"]
    F --> I["Verify NTP sync
on both servers"]
    G --> J["Verify algorithm string
and re-exchange secret"]
    H --> K["rndc retransfer zone"]
    I --> K
    J --> K

Common causes

Quick checks

Safe, read-only commands. Run on both primary and secondary for comparison. Config paths and unit names vary by distribution: /etc/named.conf and named on RHEL/Fedora, /etc/bind/named.conf and bind9 on Debian/Ubuntu.

# Compare SOA serial between primary and secondary
dig @primary-ip example.com SOA +short
dig @secondary-ip example.com SOA +short

# Check transfer-related logs on the secondary
journalctl -u named --since "1 hour ago" | grep -iE "transfer|tsig|badkey|badtime"

# Check clock synchronization on both servers
timedatectl status
chronyc tracking 2>/dev/null

# Check zone status and timing on the secondary
rndc zonestatus example.com

# Verify allow-transfer configuration
named-checkconf -p | grep -i "allow-transfer"

# Test TCP connectivity on port 53 from secondary to primary
# A REFUSED response means TCP is open but auth/ACL blocked the transfer
# A timeout means TCP/53 is blocked by a firewall
dig @primary-ip example.com AXFR +time=5

# Check key definitions on both servers
# WARNING: prints key secrets in cleartext
named-checkconf -p | grep -A5 'key "'

# Verify BIND version for known TSIG bugs
named -V | head -5

How to diagnose

1. Confirm the transfer is actually failing. Compare SOA serials between primary and secondary. If they differ and have been different for longer than the SOA refresh interval, transfers are failing or delayed.

2. Check the xfer-in logs on the secondary. This is where BIND records transfer attempts and their outcomes. Look for TSIG error codes: badkey, badtime, or badsig. The security logging category also captures authentication failures.

3. Distinguish TSIG failure from ACL refusal. If there is no TSIG error in the logs but transfers are refused, the problem is the allow-transfer ACL or network connectivity. On BIND 9.20, allow-transfer defaults to none, so an explicit ACL is required for outgoing transfers.

4. If BADKEY: compare key definitions. The key name, algorithm, and secret must match exactly on both servers. Check the key block in named.conf and any included files. The key name string is the most commonly mismatched element.

5. If BADTIME: check clock synchronization. Run timedatectl status or chronyc tracking on both servers. The default fudge is 300 seconds; a clock skew beyond 5 minutes causes rejection. NTP must be running and synchronized on both sides.

6. If BADSIG: verify the algorithm and secret. Confirm both sides use the same HMAC algorithm string (e.g., hmac-sha256). If the key was copied manually, check for transcription errors or line-wrapping in the base64 secret.

7. Check the SOA expire runway. Run rndc zonestatus <zone> on the secondary and check zone timing information. Compare the time since the last successful transfer against the SOA expire value. If the gap is approaching expiry, the secondary will stop serving the zone soon.

8. Force a transfer after fixing. Run rndc retransfer <zone> on the secondary. This forces a full AXFR regardless of serial, which can be resource-intensive for large zones. Verify the SOA serial converges.

Metrics and signals to monitor

Fixes

BADKEY: reconcile key definitions

The key name, algorithm, and base64-encoded secret must be identical on both servers. Copy the key block from one server to the other to eliminate transcription errors.

# Extract the key block from one server
named-checkconf -p | grep -A5 'key "transfer-key"'

# After updating named.conf on the other server, validate
named-checkconf

# Reload configuration on both servers
rndc reconfig

If keys were rotated as part of a security process, ensure the rotation was applied to both sides. A common operational mistake is updating the primary during a key rotation and forgetting the secondaries.

BADTIME: fix clock synchronization

Correcting NTP is the only reliable fix. Chrony is the standard on modern Linux.

# Check current sync status and offset
chronyc tracking

# Verify chronyd is running and enabled
systemctl status chronyd

# Force immediate sync if offset is large
# WARNING: steps the clock, which can disrupt TLS, database,
# and logging services on the same host
sudo chronyc -a makestep

The default TSIG fudge is 300 seconds. Even small persistent drift will eventually exceed this window if NTP is not actively correcting.

BIND 9.20 allow-transfer default

If you upgraded from BIND 9.18 to 9.20 and transfers stopped, check for an explicit allow-transfer statement. BIND 9.20 changed the default to none, meaning outgoing transfers are disabled unless explicitly configured.

# Check if allow-transfer is configured
named-checkconf -p | grep allow-transfer

# If missing, add it to the zone or options block, referencing the TSIG key:
# allow-transfer { key "transfer-key"; };

TCP/53 blocked

Zone transfers use TCP on port 53. A firewall that allows UDP/53 but blocks TCP/53 breaks transfers while normal queries continue to work. Test from the secondary:

# Test TCP connectivity to the primary
dig @primary-ip example.com SOA +tcp +time=5

If this times out while UDP works, check firewall rules between primary and secondary.

also-notify TSIG key loss on retry

If NOTIFY-triggered transfers fail intermittently but manual rndc retransfer works, you may be hitting a known bug (GitLab #6240) where the explicit TSIG key on an also-notify target is lost during the TCP retry after a failed UDP NOTIFY. The retry uses only a matching server peer key, or is sent unsigned if no peer key exists. This delays zone convergence.

Workaround: define a matching server block with a keys statement for the also-notify target, so the TCP retry has a key to use even when the explicit key is dropped.

Prevention

• Distribute keys from a single source. Store TSIG keys in configuration management and deploy to both primary and secondaries atomically. Never edit key files manually on one server at a time.

• Monitor NTP offset on all DNS servers. Clock drift causes BADTIME and DNSSEC validation failures. Alert when offset exceeds 30 seconds.

• Track SOA serial consistency continuously. Compare serials between primary and every secondary on a schedule. Any mismatch persisting beyond the SOA refresh interval indicates a transfer problem.

• Track SOA expire runway. The real danger is not serial mismatch alone but the countdown to zone expiry. Alert when remaining runway drops below 50% of the SOA expire value, and escalate at 25%.

• Validate configuration before reload. Run named-checkconf before every rndc reload or rndc reconfig. A syntax error in a key block silently breaks transfers.

• Test transfers after key changes. After any key rotation or configuration change, run rndc retransfer <zone> on the secondary and verify serial convergence within minutes.

How Netdata helps

• NTP clock offset monitoring catches the drift that causes BADTIME before it exceeds the TSIG fudge window. Correlating clock offset with transfer failures pinpoints the root cause.

• SOA serial consistency tracking flags any mismatch between primary and secondary within minutes, long before the expire countdown becomes dangerous.

• SOA expire runway monitoring converts the slow-motion transfer failure into a clear countdown signal, so you know how much time remains before the secondary stops serving the zone.

• Log correlation surfaces TSIG error codes from the xfer-in and security logging categories alongside metrics, so BADKEY, BADTIME, and BADSIG are visible in the same view as serial mismatch and clock drift.

• Process and resource monitoring for named ensures transfer failures are not caused by resource exhaustion (file descriptors, memory, TCP connection limits) that would otherwise be invisible in BIND’s own statistics.

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