BIND inline signing silently failed: missing keys and a zone served unsigned

Your BIND authoritative server is running. Queries return answers. The zone loads without error. But validating resolvers worldwide are returning SERVFAIL for your domain, and there is no error line in your logs. The zone is configured for inline signing, but it is being served unsigned.

When a zone has inline-signing yes; with auto-dnssec maintain; or dnssec-policy default;, BIND should sign the zone transparently and maintain valid RRSIG records. If the signing key files are missing from the key-directory, BIND loads the unsigned zone and serves it as-is. No startup error. No log message. No statistics counter.

The primary server-side indicators are the absence of the .signed.jnl file in the working directory and rndc signing -list <zone> returning no signing records. The authoritative server does not validate its own signatures, so it does not know it is broken. Validating recursive resolvers discover the problem first and return SERVFAIL.

How the failure works

Inline signing maintains two parallel zone versions: the unsigned master you edit, and a signed version BIND generates and serves. The signed version uses a .signed file with a .signed.jnl journal for incremental updates. When keys are present and readable, BIND signs on load, creates these files, and re-signs before RRSIG records expire.

When key files are missing, none of this happens. BIND loads the unsigned zone, creates no signed files, and serves the zone as-is. There is no error because, from BIND’s perspective, the zone loaded successfully. The signing subsystem had nothing to sign with.

This differs from a permission error. If key files exist but named cannot read them, BIND logs a clear error at startup. If the files do not exist at all, BIND logs nothing on initial startup. For secure dynamic update, BIND logs the exact string could not get zone keys for secure dynamic update. That message is not a generic inline-signing reload diagnostic; the no-keys-at-all inline-signing path returns successfully without it.

flowchart TD
    A["Zone configured for\ninline signing"] --> B{"Key files present\nin key-directory?"}
    B -- "No" --> C["Zone loads unsigned\nNo error logged\nNo .signed.jnl created"]
    B -- "Yes, but unreadable" --> D["Permission error\nlogged at startup"]
    B -- "Yes, readable" --> E["Zone signed\n.signed.jnl created"]
    C --> F{"rndc signing -list\nreturns?"}
    F -- "No signing records found" --> G["Silent failure confirmed\nZone is unsigned"]
    F -- "Signing with key..." --> H["Signing in progress"]
    F -- "Done signing with key..." --> I["Signing complete"]
    G --> J["Validating resolvers\nreject zone worldwide"]

The authoritative server never validates its own signatures. It will serve an unsigned zone indefinitely. The failure is only visible to validating recursive resolvers, which check the DNSSEC chain of trust and return SERVFAIL when signatures are missing or expired.

Common causes

Quick checks

All read-only and safe on a production server. Paths below use RHEL/CentOS conventions (/etc/named.conf, service named). On Debian/Ubuntu, substitute /etc/bind/named.conf, service bind9, and /var/cache/bind/ as appropriate.

# Primary indicator: signed journal file existence
ls -la /var/named/data/<your-zone>.signed.jnl 2>/dev/null || echo "NOT SIGNED - .signed.jnl missing"

# Signing state per zone
rndc signing -list <your-zone>

# Key files in the configured key-directory
ls -la /var/named/keys/K<your-zone>.*

# Configuration: inline-signing, dnssec-policy, auto-dnssec, key-directory
named-checkconf -p /etc/named.conf | grep -E "inline-signing|dnssec-policy|auto-dnssec|key-directory"

# Verify the zone is served unsigned
dig @127.0.0.1 <your-zone> SOA +dnssec +multiline | grep RRSIG
dig @127.0.0.1 <your-zone> DNSKEY +short
# Empty DNSKEY response = zone is not signed

# Signing-related log messages (may only appear on reload)
journalctl -u named --since "1 hour ago" | grep -i "signing\|key"

# Disk space on the key-directory partition
df -h /var/named

Diagnosis

Work through the quick checks above in this order:

1. Confirm inline signing is configured. named-checkconf -p should show inline-signing yes;, auto-dnssec maintain;, or dnssec-policy. If none are present, the zone was never configured for signing. Note: dnssec-policy (BIND 9.16+) implicitly enables inline signing without requiring an explicit inline-signing yes; directive. auto-dnssec is deprecated as of BIND 9.18.

2. Check for .signed.jnl. Its absence is the strongest single signal. If /var/named/data/<your-zone>.signed.jnl does not exist, signing never completed or never started.

3. Check rndc signing -list <zone>. Done signing with key... means success. Signing with key... means in progress. No signing records found means no signing records are currently available; correlate that result with key-file presence before concluding that keys were the cause.

4. Check for key files. Look for K<zone>.* in the configured key-directory. No keys means no signing. Common paths: /var/named/keys/, /etc/named/keys/, or the zone’s working directory.

5. Verify the zone is unsigned. No RRSIG in the dig SOA +dnssec response confirms the zone is served unsigned. An empty dig DNSKEY +short confirms no DNSKEY records are published.

6. Check logs for secure-update signing failures. Search for could not get zone keys for secure dynamic update; it identifies a dynamic-update path, not normal zone load.

7. Check disk space. With dnssec-policy, named auto-generates keys. A full partition on the key-directory prevents this.

Metrics and signals to monitor

None of these signals are available through the BIND statistics channel. There is no counter for “zone configured for signing but not signed.” Detection requires file-presence checks and RRSIG-window probes.

Fixes

Missing key files with auto-dnssec maintain (legacy method)

If you are using auto-dnssec maintain; (the original inline-signing method from BIND 9.9, now deprecated in 9.18+), BIND does not generate keys automatically. You must create them manually and load them into the zone.

Warning: Do not use this procedure if the zone was previously signed with different keys. Regenerating keys for a previously signed zone breaks the DNSSEC chain. See “Key files accidentally deleted” below.

# Generate KSK and ZSK in the configured key-directory
cd /var/named/keys
dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE <your-zone>
dnssec-keygen -a ECDSAP256SHA256 -n ZONE <your-zone>

# Ensure the named user can read the key files
# On Debian/Ubuntu, the user is typically 'bind' instead of 'named'
chown named:named K<your-zone>.*

# Load the keys into the zone (triggers signing, non-disruptive to queries)
rndc loadkeys <your-zone>

After loading keys, check rndc signing -list <your-zone> to confirm signing has started. The key algorithm should match your signing policy.

Missing key files with dnssec-policy (BIND 9.16+)

With dnssec-policy default; or a custom policy, BIND should generate keys automatically on first load. If keys are missing, the usual causes are a non-existent or non-writable key-directory, or disk-full conditions. Fix the underlying issue and force re-evaluation.

# Verify the key-directory exists and is writable by named
ls -ld /var/named/keys

# Create if missing (adjust user for Debian/Ubuntu: typically 'bind')
mkdir -p /var/named/keys
chown named:named /var/named/keys

# Check disk space
df -h /var/named

# Ask named to re-read the configuration and rekey matching zones
rndc reconfig

# Or rekey this zone directly where dnssec-policy/auto-dnssec maintain permits it
rndc loadkeys <your-zone>

Check rndc signing -list <your-zone> after rekeying to confirm signing has started. If it still does not progress after verifying directory ownership, disk space, and policy, restart named as a fallback.

Key files accidentally deleted from a previously signed zone

Do not simply regenerate keys for a zone that was previously signing correctly. Old DNSKEY records may still be cached by validating resolvers worldwide, and publishing new keys without a proper rollover sequence causes validation failures. The ISC guidance is explicit: never delete key files if they are still published in your zone and/or used for signing. It will break your DNSSEC and make the zone bogus.

If the deleted keys are still referenced by DS records in the parent zone, you need a proper key rollover. If the DS records were also removed, you need to re-establish the DNSSEC chain from scratch. Consult the BIND ARM chapter on DNSSEC for the rollover procedure specific to your situation.

Verifying recovery

In all cases, after restoring or generating keys, verify that signing completed.

# Confirm signing completed
rndc signing -list <your-zone>
# Should show "Done signing with key..."

# Verify RRSIG records are now present
dig @127.0.0.1 <your-zone> SOA +dnssec +multiline | grep RRSIG

# Verify DNSKEY records are published
dig @127.0.0.1 <your-zone> DNSKEY +short

If RRSIG records appear, the zone is signed. Cross-check from an external validating resolver to confirm the full chain of trust resolves.

Prevention

• Check .signed.jnl existence after every zone reload or restart. Cheapest, most reliable signal. Presence means signing completed; absence means it did not.
• Run rndc signing -list <zone> as a post-deploy verification step. Treat it the same way you treat named-checkconf before a reload.
• Monitor RRSIG validity windows externally. Periodic dig queries against your zones, checking the RRSIG inception and expiration timestamps, catch signing stalls before signatures expire.
• Back up key files. Treat DNSSEC key files as critical infrastructure artifacts. Store them in version control or a backup system. Deleting key files that are still published in the zone breaks DNSSEC and makes the zone bogus.
• Verify key-directory permissions after package updates. BIND package updates or system migrations can reset ownership on the key-directory, causing permission errors that ARE logged but easy to miss.
• Add file-presence monitoring for .signed.jnl. This check does not exist in BIND’s statistics channel. You need an external monitor (cron job, Nagios check, or custom script) that verifies the file exists and has been modified within a reasonable window.

How Netdata helps

Netdata’s BIND collector surfaces the statistics-channel counters that indicate broader DNSSEC health, but the specific silent-signing-failure scenario requires checks that go beyond what BIND exposes via stats.

• Correlate SERVFAIL spikes with signing events. If your zone is served unsigned, validating resolvers return SERVFAIL. Netdata’s per-second QrySERVFAIL tracking lets you see exactly when the failure started and how widespread it is.
• Track ValFail on recursive resolvers querying your zone. If you also run recursive BIND instances, rising ValFail counters for your own domain are an early downstream signal that signatures are missing or invalid.
• Monitor process health and zone load events. Netdata’s process monitoring catches restarts and reloads that may have triggered the signing failure.
• Disk space monitoring on the key-directory partition. Netdata’s disk space alerts catch the full-disk condition that prevents dnssec-policy from generating keys, giving you early warning before signing silently fails.

File existence checks for .signed.jnl and RRSIG validity window probes require external tooling. Netdata does not natively check for these. Implement them as custom checks (script-based, cron-scheduled) alongside Netdata’s metrics collection.

Related guides

• BIND DNSSEC validation failing: ‘broken trust chain’, ValFail, and SERVFAIL for signed domains
• 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 DNSSEC failing from clock drift: NTP, RRSIG inception/expiry windows, and SERVFAIL
• BIND dynamic update failures: UpdateFail, denied updates, and TSIG drift
• BIND forwarding loops: recursion that never terminates and burns recursive slots
• How BIND actually works in production: a mental model for operators
• BIND journal (.jnl) corruption: dynamic-update and IXFR failures that block zone load
• 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