BIND forwarding loops: recursion that never terminates and burns recursive slots

Recursive-clients is climbing toward its limit. SERVFAIL responses are rising across unrelated domains. QueryTimeout counters are ticking up in the per-view resolver stats. It looks like a textbook recursive resolution cascade: an upstream nameserver is slow or unreachable, in-flight queries are piling up, and BIND’s circuit breaker is about to trip.

But when you run rndc recursing to identify the culprit, the upstream IP addresses are not external nameservers. They are your own infrastructure. Another BIND resolver you control, or this very server.

That is a forwarding loop. A forwarder configuration that points (directly or transitively) back at BIND creates a cycle where queries never terminate. Each looping query holds a recursive-clients slot until a circuit breaker kills it with SERVFAIL. The loop consumes capacity as fast as you add it. Raising recursive-clients does not fix the problem; it just delays the cliff.

What it means

BIND has no built-in forwarding loop detection. When a query enters the forwarding path, BIND sends it to the configured forwarder and waits for a response. If the forwarder is another resolver that forwards back to the original server, or forwards to a third that eventually routes back, the query bounces indefinitely.

Each hop in the loop occupies a recursive-clients slot for the resolver timeout duration. With BIND’s default resolver-query-timeout of 10 seconds, a single looping query holds a slot for up to 10 seconds before the resolver gives up. During that window, the slot cannot serve any other request.

The degradation curve is cliff-edge, identical to a recursive resolution cascade from a genuinely slow upstream. At 90% of the recursive-clients limit (default: 900 out of 1000), the soft quota begins throttling clients with many outstanding recursive queries. At the hard limit of 1000, every new recursive query receives SERVFAIL, including queries for domains with perfectly healthy upstream nameservers.

BIND has several circuit breakers that eventually terminate looping queries:

• max-recursion-queries limits the number of iterative queries per client request.
• max-recursion-depth (default 7) limits delegation chain depth.
• max-query-count caps total outgoing queries per client request.

These limits prevent truly infinite loops at the code level, but they only fire after the query has already consumed time and a recursive-clients slot. The SERVFAIL they produce looks identical to any other resolution failure.

flowchart TD
    Q[Query misses cache] --> F[Forward to configured upstream]
    F --> L{Upstream is your
own resolver?}
    L -->|Yes| LOOP[Forwarding loop:
query bounces between resolvers]
    L -->|No| OK[Normal resolution
against external NS]
    LOOP --> HOLD[Each hop holds a
recursive-clients slot]
    HOLD --> FILL[Slots fill toward
recursive-clients limit]
    FILL --> SF[SERVFAIL for all new
recursive queries]

The distinguishing signal: rndc recursing shows in-flight queries waiting on IP addresses that belong to your own infrastructure, not external authoritative nameservers. If the upstream in the recursing dump is another server you manage, stop looking at external upstream health and start tracing your forward topology.

Common causes

The last row is a code-level bug, not a configuration error. CVE-2026-5950 describes an unbounded resend loop in BIND’s forwarding state machine triggered by specific bad-server handling. If your forward topology is correct and the symptoms match, verify your BIND version against the advisory.

Quick checks

# Check current recursive client count
# Statistics channel port is set via 'statistics-channels' in named.conf
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
  print('RecursClients:', d.get('nsstats',{}).get('RecursClients','N/A'))"

# Dump in-flight recursive queries and identify upstream IPs
# Output format varies by BIND version; adjust the awk pattern as needed
rndc recursing | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

# Check resolver timeout rate (per-view)
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 sorted(vd.get('resolver',{}).get('stats',{}).items()) \
  if k in ('QueryTimeout','SERVFAIL','Retry')]"

# Inspect forward configuration
named-checkconf -p /etc/named.conf 2>/dev/null | grep -A5 "forward"

# Check SERVFAIL rate
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'))"

# Verify whether a specific forwarder is reachable and responds
dig +time=2 +tries=1 @<forwarder-ip> example.com A

If the rndc recursing output shows upstream IPs in your own RFC 1918 space, your anycast range, or loopback, you almost certainly have a forwarding loop. The next step is tracing the forward chain to find where the cycle closes.

How to diagnose it

1. Confirm the cascade pattern. Check that RecursClients is elevated (above 50% of the limit is concerning; above 90% is critical), QrySERVFAIL is rising, and QueryTimeout is increasing. All three should trend together. If only SERVFAIL is rising without RecursClients climbing, look at DNSSEC validation failures or zone load failures instead.

2. Identify the upstream IPs in rndc recursing. Run the awk pipeline from the quick checks. If the top upstream IPs are external (root servers, TLD nameservers, external authoritative providers), you have a genuine upstream slowness problem, not a forwarding loop. If they are internal IPs, proceed to step 3.

3. Trace the forward chain. On each resolver in the chain, inspect the forwarders directive. Follow the chain: if resolver A forwards to resolver B, check what B forwards to. If B forwards back to A, or to C which forwards to A, you have found the loop.

4. Test forwarder reachability directly. Use dig @<forwarder-ip> <test-domain> A to verify the forwarder is actually responding. A forwarder that is up but forwarding back to you will respond, but slowly: it is itself waiting for its own upstream, which is you.

5. Check for mixed forward modes. BIND’s forward directive defaults to first, meaning if the forwarder fails, BIND falls back to normal recursion against root servers. A zone configured with forward only never falls back. If some zones use forward only and the forwarder is in a loop, those zones fail while others work, creating an intermittent pattern that is easy to misdiagnose.

6. Verify BIND version if the configuration looks correct. If every forwarders directive terminates at a genuine recursive resolver and no cycle exists, but symptoms persist, check whether CVE-2026-5950 applies to your version (see the Common causes table).

Metrics and signals to monitor

The correlation that distinguishes a forwarding loop from a regular upstream cascade: the upstream IPs in rndc recursing are internal. No single statistic channel counter will tell you this directly. You need to look at the recursing dump and recognize your own IP space.

Fixes

Remove the forwarding loop

The only real fix is to correct the forward configuration so no cycle exists. Identify where the forward chain closes and remove or redirect the offending forwarders directive.

For a two-resolver mutual loop: each resolver lists the other as its forwarder. At least one must forward to a genuine upstream (root servers, an ISP resolver, or a recursive resolver that does not forward back).

For a self-loop: the server’s forwarders directive contains its own IP address. Remove it.

For a transitive loop: trace the full chain and break the cycle at any point. The simplest approach is to ensure that at least one resolver in the chain performs full recursion rather than forwarding.

Validate before reloading

# Validate configuration syntax before applying
named-checkconf /etc/named.conf

# Inspect the corrected forward configuration
named-checkconf -p /etc/named.conf 2>/dev/null | grep -A5 "forward"

Apply the change with rndc reconfig (reloads configuration without dropping the cache) or rndc reload (reloads zones and configuration).

Flush affected cache entries after the fix

BIND caches SERVFAIL responses for servfail-ttl seconds (default 1 second). If servfail-ttl has been increased, or if affected domains accumulated NXDOMAIN or NODATA entries during the loop, those cached responses persist after the fix. Flushing clears them immediately:

# Flush a specific domain (less disruptive)
rndc flushname example.com

# Flush the entire cache (disruptive: clears all cached entries)
rndc flush

Do not just raise recursive-clients

Increasing recursive-clients from 1000 to 2000 does not fix the loop. It doubles the number of slots the loop can consume before the circuit breaker trips, delaying the SERVFAIL cliff but making the eventual saturation worse. The loop generates unbounded demand; no finite limit solves it.

Raising recursive-clients without corresponding increases in file descriptor limits and memory can also cause FD exhaustion or memory pressure before the recursive client limit is reached. Each recursive query consumes file descriptors and memory; scaling the limit without scaling the underlying resources shifts the failure mode; it does not prevent it.

For deeper coverage of the circuit breaker itself, see BIND ’no more recursive clients: quota reached’: the recursive-clients circuit breaker.

Prevention

Validate forward topology before deployment. Before adding or changing a forwarders directive, trace the chain to its termination. Every forward chain must end at a resolver that performs full recursion (querying root servers directly), not at another forwarder.

Document the forward topology. Maintain a record of which resolver forwards to whom. A forwarding loop is usually created when someone adds a forwarder without knowing the existing chain. “Resolver A forwards to B” is a fact that should be recorded, not rediscovered during an incident.

Sample rndc recursing periodically. This is Level 4 monitoring maturity. Sampling the upstream IPs in the recursing dump and alerting when internal IPs appear unexpectedly catches forwarding loops before they saturate recursive-clients. See the BIND monitoring maturity model for where this fits.

Use forward first deliberately. The default forward first mode falls back to root servers if the forwarder fails, which can mask a partial loop. If you intentionally use forward only, any forwarder misconfiguration will produce immediate failures rather than degraded-but-working behavior. Choose based on your failover requirements and document why.

Run named-checkconf in pre-deploy hooks. Syntax validation catches malformed forwarders directives but cannot detect logical loops (it does not know which IPs belong to which servers). Pair it with a topology check that verifies no forward chain cycles back on itself.

How Netdata helps

• Per-second RecursClients tracking: a forwarding loop drives RecursClients upward monotonically. Per-second granularity exposes the trend before the soft quota engages.
• Correlated SERVFAIL and QueryTimeout: when RecursClients, QrySERVFAIL, and QueryTimeout all trend upward simultaneously, the composite pattern points at a recursive resolution cascade, whether from a forwarding loop or a genuinely slow upstream.
• Per-view NumFetch and resolver stats: isolates the problem to a specific view in split-horizon deployments, useful when one view has a forwarding loop and another does not.
• Cache hit ratio decline: a forwarding loop prevents cache population for affected domains, driving hit ratio down before RecursClients saturates.
• Anomaly detection on RecursClients and QueryTimeout baselines flags deviations that may indicate a loop introduced by a recent configuration change.

Related guides

• 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 NXDOMAIN spike: DGA malware, water torture, and Windows suffix search lists
• BIND REFUSED responses: ACL denials, recursion policy, and clients that get locked out
• rndc not responding: control-plane failure while queries still work
• BIND SERVFAIL responses: what a DNS SERVFAIL actually means and how to trace the cause