BIND lame delegations: 'lame server resolving' and nameservers that are not authoritative

The lame server resolving message in BIND’s lame-servers log category means the resolver contacted a delegated nameserver that answered but was not authoritative for the zone it was supposed to serve. Each lame encounter wastes a fetch cycle and adds latency. On busy resolvers with high query volume for affected zones, the cost compounds. The per-view Lame counter in resolver statistics tracks how often this happens.

Since CVE-2021-25219—published on 27 October 2021 and patched in BIND 9.11.36, 9.16.22, and 9.17.19—the lame-ttl default is 0, effectively disabling the lame cache. The option still exists in the configuration grammar, but explicit non-zero values are ignored. Before this change, the default was 600 seconds: BIND cached lame indications and skipped the offending server on subsequent queries within that window. Now every query for a zone with a lame delegation contacts that server from scratch, burning a full fetch cycle each time.

What this means

When BIND resolves a name recursively, it follows the delegation chain from the root down. At each delegation point, the parent zone lists a set of NS records. BIND contacts those nameservers expecting them to be authoritative for the delegated zone. A server is lame when it responds but does not have the zone loaded, returning a referral or non-authoritative answer instead of the expected authoritative data.

ISC defines three categories of problematic delegated servers:

• Type 1 (lame): The server responds but gives non-authoritative information. Tracked by the Lame counter.
• Type 2 (unreachable): The server does not respond at all. Tracked by QueryTimeout, not Lame.
• Type 3 (refused or error): The server responds with REFUSED or an error code. Not counted as lame.

A timed-out server (QueryTimeout) is a distinct problem from a lame server (Lame). Both waste a recursive-client slot, but the root causes and fixes differ.

With the lame cache effectively disabled (lame-ttl default 0), every recursive query for a zone with a lame delegation repeats the full cycle: contact the lame NS, discover it is not authoritative, try the next NS in the delegation. If the lame server is first in BIND’s server selection order (influenced by RTT estimates), it gets tried first on every query.

The operational impact scales with query volume. A single lame NS in a delegation with three healthy NS records adds modest latency per query. A zone where two of three NS records are lame, combined with high query volume, produces a sustained increase in outbound fetches, longer recursive-client slot occupancy, and potentially elevated SERVFAIL if all NS records are problematic.

The interaction with max-recursion-queries (default 50 in the affected BIND 9.20 releases) makes this worse. Each NS hostname in a delegation may itself require resolution, triggering A and AAAA lookups. Lame delegations that force BIND to try multiple NS records burn through the per-query recursion budget faster. When that budget is exhausted, BIND returns SERVFAIL.

flowchart TD
    A[Recursive query - cache miss] --> B[Follow delegation to NS records]
    B --> C[Try first NS]
    C --> D{Server responds?}
    D -->|No response| E[QueryTimeout]
    E --> F[Try next NS]
    D -->|Responded| G{Authoritative for zone?}
    G -->|Yes| H[Return answer]
    G -->|No - lame| I[Log: lame server resolving]
    I --> J[Lame counter increments]
    J --> F
    F --> K{More NS records?}
    K -->|Yes| C
    K -->|No| L[SERVFAIL]

Common causes

Quick checks

# Check the lame-servers log for affected zone names
grep "lame server resolving" /var/log/named/lame-servers.log | tail -20

# Or if lame-servers is not routed to a separate file:
journalctl -u named --since "1 hour ago" | grep "lame server resolving"

# Check per-view Lame counter (cumulative since startup)
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
  [print(f'{v}: Lame={vd.get(\"resolver\",{}).get(\"stats\",{}).get(\"Lame\",\"N/A\")}') \
  for v,vd in d.get('views',{}).items()]"

# Check QueryTimeout alongside Lame for comparison
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
  [print(f'{v}: Lame={s.get(\"Lame\",0)} QueryTimeout={s.get(\"QueryTimeout\",0)}') \
  for v,vd in d.get('views',{}).items() \
  for s in [vd.get('resolver',{}).get('stats',{})]]"

# Check whether lame-ttl is explicitly configured (will not appear if using the default)
named-checkconf -p /etc/named.conf | grep lame-ttl

# Check max-recursion-queries setting (will not appear if using the default)
named-checkconf -p /etc/named.conf | grep max-recursion-queries

# Test whether a specific NS is authoritative for the zone
dig +norecurse +time=2 +tries=1 @<ns-ip> <zone-name> SOA
# Look for the "aa" (authoritative answer) flag in the response headers

# Check which upstream servers are currently being waited on
rndc recursing | head -30

# Check SERVFAIL rate for correlation
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
  print('QrySERVFAIL:', d.get('nsstats',{}).get('QrySERVFAIL','N/A'))"

The statistics channel port (8653 above) is configurable. BIND distributions commonly use 8053 or 8653. Check your statistics-channels configuration for the actual port.

How to diagnose it

1. Identify the affected zone from lame-servers logs. The lame server resolving message includes the query name and the lame server’s address. Filter by zone name to find which delegations are broken. If the lame-servers category is not routed to a separate file, messages appear in the default query or resolver logs depending on your logging configuration.

2. Extract the NS records for the affected zone from the parent. Query the parent zone’s delegation to see which NS records it publishes:

   # For a .com domain, query the gtld servers
   dig @a.gtld-servers.net example.com NS +short
   
   # Or trace the full delegation path from the root
   dig +trace example.com NS
   

3. Test each NS for authority. For each NS record found, check whether it is actually authoritative for the zone:

   for ns in $(dig @a.gtld-servers.net example.com NS +short); do
     echo -n "$ns: "
     dig +norecurse +time=2 +tries=1 @$ns example.com SOA +short | head -1
   done
   

   A server that returns nothing, returns a referral, or lacks the aa flag is lame.

4. Check for version-specific delegation issues. If running BIND 9.20.17 through 9.20.19 and seeing resolution failures alongside lame-server messages for zones with NS hostnames in sibling zones, this is a known regression. The workaround is to configure the affected zone as type static-stub or increase max-recursion-queries.

5. Check for cyclic delegation patterns. A zone whose NS hostnames delegate to another zone whose NS hostnames delegate back creates a loop. BIND 9.20.20 has been observed spawning multiple parallel hung-fetch objects that persist for about 12 seconds before returning SERVFAIL, as reported in ISC GitLab issue #5815; that report also observed fast SERVFAIL behavior in Unbound, PowerDNS Recursor, and Knot Resolver under the same cyclic-zone test.

6. Correlate Lame with QueryTimeout and SERVFAIL. A rising Lame counter alongside rising QueryTimeout suggests a mix of unreachable and non-authoritative NS records in the same delegation. A rising Lame counter alongside SERVFAIL for the same zone tree suggests the delegation is sufficiently broken that BIND cannot resolve the zone at all.

Metrics and signals to monitor

Fixes

Fix the delegation in the parent zone

If the parent zone lists an NS that no longer serves the child zone, update the parent’s delegation. Remove the stale NS record and ensure remaining NS records are correct. This requires access to the parent zone’s administrative interface or zone file. If you do not control the parent zone, contact the registrar or the parent zone’s operator.

Fix the lame nameserver

If the NS is supposed to be authoritative but the zone is not loaded, investigate why. Common causes include missing zone file, configuration error, failed zone transfer, or DNSSEC signing failure. On the affected NS:

rndc zonestatus <zone-name>
named-checkzone <zone-name> /path/to/zone/file
journalctl -u named | grep "<zone-name>"

Workaround for BIND 9.20.17+ sibling NS regression

Zones where NS hostnames are in sibling zones that reference each other can cause resolution failure on a cold resolver in the affected releases. Two options:

• Configure the affected zone as type static-stub with explicit server addresses, bypassing delegation chain resolution for that zone.
• Increase max-recursion-queries in the resolver options. This allows more queries per resolution but increases resource usage under pathological delegation conditions.

max-recursion-queries can be set at the options or view level.

Forward specific broken zones

If the delegation is broken upstream and you cannot fix it, configure BIND to forward queries for that zone to a resolver that handles it correctly. This bypasses normal delegation resolution entirely:

zone "broken-zone.example" {
    type forward;
    forwarders { <working-resolver-ip>; };
};

Prevention

• Monitor the per-view Lame counter as a trend. A sudden sustained increase from baseline points to a newly broken delegation, not transient noise.
• Route lame-servers logs to a dedicated file. ISC recommends a separate logging channel for the lame-servers category to prevent flooding the general resolver log and to simplify pattern analysis.
• Validate delegation before publishing zone changes. When adding or removing NS records, verify that all listed servers are actually authoritative using dig +norecurse.
• Check delegation health after registrar changes. NS record changes at the registrar level can create stale delegations that persist until TTL expiry across the resolver ecosystem.
• Track max-recursion-queries exhaustion. If logs show recursion query limits being hit, investigate whether lame delegations are burning the query budget.

How Netdata helps

• The per-view Lame counter is collected per second, so you can pinpoint the exact moment a broken delegation starts generating lame responses rather than discovering it from cumulative counters.
• Lame, QueryTimeout, NumFetch, and RecursClients appear in the same dashboard view, making it fast to determine whether a delegation has a mix of unreachable and non-authoritative servers or whether retries are consuming resolver capacity.
• Correlating Lame trends with QrySERVFAIL shows when broken delegations escalate to user-visible failures.
• Anomaly detection on the Lame counter flags sudden deviations from baseline before SERVFAIL spikes appear.

Related guides

• BIND forwarding loops: recursion that never terminates and burns recursive slots
• How BIND actually works in production: a mental model for operators
• 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
• BIND resolver NumFetch per view: per-view recursive pressure in split-horizon setups
• BIND NXDOMAIN spike: DGA malware, water torture, and Windows suffix search lists
• BIND recursive resolution cascade: one slow upstream taking down all resolution
• BIND RecursClients climbing toward the limit: reading the recursive saturation gauge
• BIND REFUSED responses: ACL denials, recursion policy, and clients that get locked out
• rndc not responding: control-plane failure while queries still work