BIND dnssec-validation disabled: the security regression that 'fixes' SERVFAIL

SERVFAIL on signed domains is a real production problem. Users cannot reach major services because .com, .org, google.com, and countless other zones are DNSSEC-signed. When validation fails, those names stop resolving. The pressure to restore service is immediate.

The fastest way to make the SERVFAIL disappear is one line in named.conf:

dnssec-validation no;

After a reload, every signed domain resolves again. The monitoring dashboard goes green. The ticket closes. Everything works, including cache-poisoning attacks. The resolver now accepts forged responses for every query it processes.

What this means

dnssec-validation no; tells BIND to skip cryptographic validation of all DNS responses. The resolver still fetches records from upstream, caches them, and serves them to clients. It performs no signature verification. A forged response with bogus RRSIG records, expired signatures, or no signatures at all will be accepted and cached identically to a legitimate one.

The default on BIND 9.16 and later is dnssec-validation auto;. In auto mode, BIND loads the IANA root trust anchor from its built-in managed keys and performs RFC 5011 automatic trust anchor rollover. No manual trust-anchor configuration is needed. Setting the option to no removes this protection entirely.

A related misconfiguration produces the same silent failure: setting dnssec-validation yes; without a trust-anchors statement. On BIND 9.18 and earlier, validation is nominally “enabled” but has no trust anchors to validate against, so no actual validation occurs. Since BIND 9.20, the gap is closed: dnssec-validation yes; without a trust-anchors statement is a configuration error and named refuses to start.

When validation is disabled, the ValAttempt counter in per-view resolver statistics drops to zero. The resolver is no longer attempting to validate any response. This is the definitive statistical signal.

Common causes

Quick checks

# Check the effective configuration.
# If grep returns nothing, the option is not explicitly set and the default applies
# (auto on BIND 9.16+, yes with built-in keys on older versions).
named-checkconf -p /etc/named.conf | grep -i "dnssec-validation"

# Functional test: AD flag present means validation is working.
# +dnssec sets the DO bit, which is required for the resolver to return AD.
dig +dnssec @127.0.0.1 google.com A | grep -E "flags:|status:"

# Failure test: this domain is intentionally DNSSEC-broken.
# A validating resolver returns SERVFAIL; a non-validating one returns an A record.
dig @127.0.0.1 dnssec-failed.org A +time=2 +tries=1

# Confirm with +cd (Checking Disabled): bypasses validation.
# If this returns NOERROR, the failure is in validation, not upstream reachability.
dig @127.0.0.1 dnssec-failed.org A +cd +time=2 +tries=1

# Check ValAttempt counter (should be > 0 on a validating resolver with traffic).
# Per-view resolver counters live at views.<view>.resolver.stats.<counter> in
# the /json/v1/server output. Port 8653 is an example; replace with your
# configured statistics-channel port.
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
  [print(f'{v}: {k}={s}') for v,vd in d.get('views',{}).items() \
  for k,s in vd.get('resolver',{}).get('stats',{}).items() if k.startswith('Val')]"

# Check managed keys / trust anchor state
rndc managed-keys status

Interpreting the results:

• AD flag absent on dig +dnssec output: validation is disabled or broken. A validating resolver sets the AD (Authenticated Data) flag when it successfully validates a response, but only if the client sent the DO bit via +dnssec.
• dnssec-failed.org returns NOERROR instead of SERVFAIL: validation is disabled. This domain has deliberately broken DNSSEC. A validating resolver must reject it.
• ValAttempt is 0: the resolver is not attempting any validation. Statistical confirmation.
• rndc managed-keys status: shows the state of RFC 5011 trust anchors. Missing or stale keys explain why validation was failing in the first place.

How to diagnose it

flowchart TD
    A["SERVFAIL on signed domains"] --> B{"dig +cd returns NOERROR?"}
    B -- No --> C["Not a DNSSEC issue.
Check zone data or upstream."]
    B -- Yes --> D["DNSSEC validation failure confirmed"]
    D --> E["Identify root cause before disabling"]
    E --> F["Clock drift"]
    E --> G["Stale trust anchors"]
    E --> H["Forwarder strips DNSSEC"]
    E --> I["Broken upstream zone"]
    F --> J["Fix NTP"]
    G --> K["Refresh managed keys"]
    H --> L["Fix forwarder chain"]
    I --> M["rndc nta for per-domain NTA"]
    J --> N["Validation stays ON"]
    K --> N
    L --> N
    M --> N
    D --> X["WRONG PATH: dnssec-validation no"]
    X --> Y["ALL validation disabled
Forged responses accepted"]

1. Confirm DNSSEC is the root cause. Run dig @127.0.0.1 <signed-domain> A (SERVFAIL) and dig @127.0.0.1 <signed-domain> A +cd (NOERROR). If +cd succeeds, the problem is validation, not upstream reachability.

2. Check the clock. DNSSEC signatures have inception and expiration timestamps. Even modest clock drift can cause validation failures. Run timedatectl status or chronyc tracking. A drift of more than a few minutes is enough to break validation. See BIND DNSSEC failing from clock drift for the full diagnosis path.

3. Check trust anchor state. Run rndc managed-keys status. This shows whether the root KSK trust anchor is present and its RFC 5011 state. A corrupted managed-keys database or a stale key after a KSK rollover causes broad validation failure.

4. Check for forwarder interference. If BIND forwards queries through another resolver that does not pass DNSSEC records (or returns unsigned data for signed zones), validation fails. Test the forwarder directly: dig +dnssec @<forwarder-ip> example.com. If the forwarder does not return RRSIG records, BIND cannot validate the chain.

5. Check if the failure is broad or specific. Broad failure across many unrelated domains points to a local problem (clock, trust anchor). Failure for one domain or one zone’s children points to an upstream signing issue.

6. Check current config state. Run named-checkconf -p | grep dnssec-validation. If it returns no, someone already applied the nuclear option. If it returns yes but no trust-anchors block exists (on BIND 9.18 or earlier), validation is silently inactive.

Metrics and signals to monitor

Fixes

Re-enable validation

Set the option back to auto and reload:

# Edit named.conf, set:
# dnssec-validation auto;

named-checkconf /etc/named.conf   # validate config syntax
rndc reload                        # apply

After reload, confirm with the functional tests above. ValAttempt should begin climbing within seconds as queries arrive.

Fix clock drift

If NTP failure caused the original SERVFAIL, fixing the clock is the actual fix. BIND’s managed keys and signature validation depend on accurate time. After the clock stabilizes, validation resumes automatically. No config change needed.

Refresh trust anchors

If rndc managed-keys status shows stale or missing keys:

rndc managed-keys status

A corrupted managed-keys database may need to be rebuilt. The exact file path depends on your distribution, but the keys are typically in the working directory specified in named.conf.

Use per-domain exceptions instead of global disable

BIND provides mechanisms to exclude specific domains from validation without disabling it globally:

• rndc nta <domain>: Creates a Negative Trust Anchor. This temporarily disables validation for a specific domain without editing named.conf. Use this when an upstream zone has broken DNSSEC and you are waiting for the zone owner to fix it. This is the operational best practice for handling broken domains.

• validate-except: Excludes a domain subtree from validation in the config. Syntax: validate-except { "subdomain.example.net"; };. This persists across restarts, unlike rndc nta, whose negative trust anchors expire.

These tools let you handle a single broken domain while keeping validation active for everything else.

Fix the forwarder chain

If BIND forwards through a resolver that strips DNSSEC data, either configure the forwarder to pass DNSSEC records through or switch to direct recursion for signed zones. Disabling validation to work around a broken forwarder chain trades a temporary inconvenience for a permanent security hole.

Prevention

Treat any change to dnssec-validation as a security event. Alert on its presence in named.conf and its effective value in named-checkconf -p output.

Run functional canary checks. Periodically query a deliberately broken DNSSEC domain and verify the resolver returns SERVFAIL. If it starts returning NOERROR, validation has been disabled or broken.

Watch ValAttempt. A sustained zero on a resolver with active query traffic means validation is off. This is a statistical canary that does not depend on external test domains.

Enforce change management on DNS config. The dnssec-validation no; fix is typically applied under pressure during an incident. A review gate or automated config check that flags this setting prevents it from persisting after the original issue is resolved.

Document the expected forwarder behavior and validate it before going to production. Forwarder-mode deployments are the most common context where operators reach for this setting.

How Netdata helps

• ValAttempt and ValFail tracking: Netdata collects per-view DNSSEC validation counters from the BIND statistics channel. A drop of ValAttempt to zero is an immediate, unambiguous signal that validation has been disabled. Trending these counters over time makes the regression visible even if no one is looking at the config file.
• SERVFAIL rate correlation: When SERVFAIL spikes, correlating it with ValFail and ValAttempt helps distinguish “DNSSEC is broken” from “validation was turned off.” A SERVFAIL spike with rising ValFail means validation is catching bad signatures. A SERVFAIL drop to zero with ValAttempt also at zero means someone disabled validation.
• Config-aware alerting: Monitoring the effective dnssec-validation setting alongside the validation counters provides defense in depth. If the config says auto but ValAttempt is zero, there is a different problem (missing trust anchors, yes without trust-anchors). If the config says no, the regression is confirmed.
• Per-second granularity: DNSSEC validation events are often transient. A spike in ValFail that lasts 30 seconds and resolves (clock corrected, trust anchor refreshed) is invisible with 5-minute polling. Per-second collection captures it.
• Composite pattern detection: Correlating SERVFAIL rate, ValAttempt, ValFail, NTP offset, and recursive client count in a single view makes it obvious whether validation was disabled as a workaround or failed organically.

Related guides

• BIND DNSSEC validation failing: ‘broken trust chain’, ValFail, and SERVFAIL for signed domains
• BIND DNSSEC failing from clock drift: NTP, RRSIG inception/expiry windows, and SERVFAIL
• 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 forwarding loops: recursion that never terminates and burns recursive slots
• How BIND actually works in production: a mental model for operators
• BIND max-cache-size: sizing the resolver cache without triggering the OOM killer