BIND RRSIG expiry on authoritative zones: the silent signing time bomb

Your zone is down. Validating resolvers worldwide return SERVFAIL for every query to your domain. But the authoritative server looks fine: named is running, port 53 is listening, the statistics channel shows normal traffic. No errors in the logs. No alerts fired.

The problem is expired RRSIG signatures. BIND’s authoritative server does not validate its own signatures at serve time. It will serve expired RRSIGs indefinitely, and every validating resolver that queries your zone will reject the response. The outage is invisible from the server itself.

This is not exposed through the BIND statistics channel. There is no counter for RRSIG validity, no log entry when signatures expire, and no error from named. The only way to catch this before it becomes a full outage is to externally monitor the RRSIG validity window on your signed zones.

What this means

When inline signing is enabled, BIND maintains a signed version of the zone (with RRSIG records) alongside the unsigned master file. Each RRSIG record has an inception timestamp and an expiration timestamp defining its cryptographic validity window.

The signing process normally refreshes signatures before they expire. With dnssec-policy, the signing schedule is governed by configurable refresh and validity intervals. If signing silently stops, the existing signatures continue to be served but are never refreshed.

flowchart TD
    A[Signing process stops] --> B[RRSIGs not refreshed]
    B --> C[Signatures approach expiry]
    C --> D[Signatures expire]
    D --> E[Validating resolvers reject zone]
    E --> F[Worldwide SERVFAIL]

The authoritative server serves RRSIG records from the signed zone file regardless of whether they are still within their validity window. RFC 4641 notes there is no coupling between RRSIG expiration and the SOA expire parameter. These are independent timers with independent failure modes.

Since most major public resolvers and many enterprise resolvers validate DNSSEC by default, expired RRSIGs effectively take your zone offline for a significant fraction of users. The only signals appear on those validating resolvers, which return SERVFAIL to clients who depend on DNSSEC validation.

Common causes

Cause	What it looks like	First thing to check
Key file missing	Zone serves stale signatures, `.signed.jnl` not updated; if a public DNSKEY remains in the zone, BIND logs a key-read warning	`ls -la /var/named/data/<zone>.signed.jnl`
Key file permission denied	Error in `dnssec` log category, signing does not start after reload	Check ownership on key files in the zone’s key directory
Disk full	Signing cannot write `.signed.jnl` or updated signed zone	`df -h` on the partition holding zone data
Signing process stuck	`rndc signing -list <zone>` shows “Signing with key…” indefinitely	Check BIND logs for repeating signing messages or errors
`dnssec-policy` misconfiguration	Policy does not match existing key states, or migration from `auto-dnssec` left orphaned state	Review `dnssec-policy` stanza and key state

Quick checks

# Check RRSIG validity window for a zone (primary diagnostic)
dig @127.0.0.1 <your-zone> RRSIG +dnssec +multiline | grep -A2 "RRSIG"
# Each RRSIG record shows expiration and inception timestamps.
# If the expiration timestamp is in the past, signatures have expired.

# Check signing state
rndc signing -list <your-zone>
# "Done signing with key..." = last signing cycle complete
# "Signing with key..." = signing in progress
# No output or error = signing may not be running

# Detect silent signing failure: missing .signed.jnl means zone is NOT being signed
# NOTE: path depends on your configuration; /var/named/data/ is the BIND default
ls -la /var/named/data/<your-zone>.signed.jnl 2>/dev/null || echo "NOT SIGNED"

# Check for signing-related log messages
# Service name may be 'named' or 'bind9' depending on your distribution
journalctl -u named --since "1 hour ago" | grep -i "signing\|rrsig\|inline"

# Confirm from a validating resolver's perspective (if you have access to one)
dig @<validating-resolver> <your-zone> A        # SERVFAIL if RRSIGs are expired
dig @<validating-resolver> <your-zone> A +cd    # NOERROR with checking disabled = DNSSEC confirmed

# Verify the zone itself is loaded and serving
dig @127.0.0.1 <your-zone> SOA +norecurse +short

How to diagnose it

Verify the zone is loaded and serving. Run dig @127.0.0.1 <zone> SOA +norecurse +short. A valid SOA response means the zone is loaded. The problem is DNSSEC, not the zone data itself.
Check RRSIG expiration timestamps. Run dig @127.0.0.1 <zone> RRSIG +dnssec +multiline and examine the output. Each RRSIG record includes an expiration timestamp. If the expiration is in the past, your signatures have expired and the zone is being rejected by validating resolvers.
Check signing state with rndc. Run rndc signing -list <zone>. If it shows “Done signing with key…”, the last signing cycle completed. If it shows nothing or an error, the signing process may have stopped. This command shows key signing state, not RRSIG validity. It does not tell you when signatures will expire.
Check for the .signed.jnl file. Run ls -la /var/named/data/<zone>.signed.jnl. If this file is missing, inline signing is not running for the zone. This is the signature of a silent signing failure: no log error, no statistics counter, just an absent file.
Review BIND logs for signing errors. Run journalctl -u named --since "24 hours ago" | grep -i "signing\|dnssec\|key\|permission". When a public DNSKEY remains in the zone but its private component is unreadable, BIND logs a warning such as dns_zone_findkeys: error reading ...: file not found on 9.20 or dns_dnssec_findzonekeys2: error reading ...: file not found on 9.16/9.18. If no key files exist at all, the no-keys path can still be silent.
Confirm from an external validating resolver. If possible, query your zone from a validating resolver with and without the +cd flag. If +cd queries succeed but normal queries return SERVFAIL, expired RRSIGs are confirmed as the cause.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
RRSIG remaining validity	Direct countdown to outage	Remaining validity drops below re-sign interval plus margin (e.g., <48 hours)
`.signed.jnl` file presence	Absence means silent signing failure	File missing for a zone that should be inline-signed
`rndc signing -list` output	Shows whether signing is active or stalled	“Signing with key…” that never transitions to “Done”
QrySERVFAIL on downstream resolvers	Downstream effect of expired signatures	SERVFAIL spike for your zone on validating resolvers
BIND dnssec log category	Catches permission errors and key issues	New error entries after config changes or restarts
Disk space on zone data partition	Full disk prevents signing writes	Free space dropping below safe threshold

Fixes

If signatures have already expired:

Fix the underlying cause first (see below), then trigger a new signing cycle with rndc sign <zone>. This updates zone keys and re-signs as needed, regenerating RRSIGs with fresh validity windows. After re-signing completes (verify with rndc signing -list <zone>), the zone serves valid signatures again. Validating resolvers pick up the new signatures on their next query once their negative cache (SERVFAIL) TTL expires.

If the key file is missing:

This is the most insidious failure mode. The zone continues serving but with stale or unsigned data. The only evidence is the absence of the .signed.jnl file. Locate the key directory for the zone (typically the zone’s directory or a key-directory option). If key files are genuinely missing, you must regenerate them, which may require re-establishing the DS record at the parent zone. Do not attempt key regeneration without understanding the full KSK/ZSK lifecycle for your zone.

If key file permissions are wrong:

The named process must read key files and write the .signed.jnl file. Check ownership: key files and the zone data directory should be owned by the user named runs as. Fix permissions, then run rndc sign <zone>.

If disk is full:

Free space on the partition holding zone data. BIND cannot write the .signed.jnl file or the updated signed zone without available disk space. After freeing space, run rndc sign <zone>.

If dnssec-policy migration caused the problem:

If you recently migrated from auto-dnssec to dnssec-policy, key state may be inconsistent. The auto-dnssec option was deprecated in BIND 9.16 and removed in BIND 9.20.0; use dnssec-policy or manual signing instead. Verify that your key files are in the format expected by dnssec-policy and that the policy configuration matches your existing key states.

Prevention

Monitor RRSIG expiry externally. This is the single most important preventive measure. Run a scheduled check (hourly or more frequently) that queries each signed zone for RRSIG records and computes remaining validity. Alert when remaining validity drops below the re-sign interval plus a safety margin. A 48-hour threshold is a reasonable starting point.
Check .signed.jnl presence after every restart and reload. A missing .signed.jnl file is the signature of silent signing failure. Include this check in your post-deploy verification procedure.
Pre-validate configuration before reload. Run named-checkconf and named-checkzone before every rndc reload. A syntax error in the dnssec-policy stanza can silently break signing.
Monitor disk space on the zone data partition. Disk full conditions prevent signing writes. Set alerts well before the partition reaches capacity.
Track key file integrity. Ensure key files are backed up, have correct permissions, and are not accidentally modified or deleted by automation.
Post-reload verification. After every rndc reload or restart, verify that all signed zones have fresh RRSIGs and that .signed.jnl files exist. Do not assume that a successful reload means signing is working.

How Netdata helps

The RRSIG validity window is not exposed through BIND’s statistics channel, so no statistics-channel-based collector can directly report signature expiry. However, Netdata can surface several correlated signals that shorten time-to-diagnosis:

SERVFAIL rate monitoring. A spike in QrySERVFAIL on validating resolvers that query your zone is the downstream symptom of expired RRSIGs. Per-second QrySERVFAIL collection makes this visible immediately rather than after users report failures.
Zone load health. If signing failure also prevents zone load, zone status checks catch the failure at reload time rather than waiting for external reports.
Process resource metrics. Disk full conditions, memory pressure, or file descriptor exhaustion that could cause signing to fail are visible through system-level collectors (disk space, memory, file descriptors).
Correlation across layers. Netdata’s unified timeline lets you correlate a BIND restart, a config change, or a disk space alert with a subsequent signing failure, compressing what would be hours of log diving into a single dashboard view.

For direct RRSIG expiry monitoring, deploy an external synthetic check that queries each signed zone for RRSIG records and alerts on remaining validity. This complements statistics-channel-based collection rather than replacing it.