BIND open recursive resolver: DNS amplification abuse and allow-recursion posture

An open recursive resolver answers recursive DNS queries from any source address. BIND configured with allow-recursion { any; } serves legitimate clients, but it also serves attackers: spoofed source IPs turn your resolver into a DDoS amplification relay, where small queries produce large responses directed at victims you have never heard of.

The abuse can be invisible. If the attack volume is small relative to your legitimate traffic, query rates look normal, cache hit ratios look healthy, and SERVFAIL rates stay flat. The only evidence is in the configuration itself and in subtle traffic pattern shifts: elevated ANY or TXT query shares, high source-IP diversity, or responses going to networks that have no business querying your resolver.

This is a posture issue, not an acute operational fault. Some resolvers are intentionally public. Most enterprise and infrastructure resolvers should not be.

Prerequisites

• BIND 9.4.1-P1 or later. That release fixes CVE-2007-2925 by applying the restricted localnets; localhost; defaults to allow-recursion and allow-query-cache. Unpatched BIND 9.4.0, 9.4.1, and 9.5.0a1 through 9.5.0a5 do not apply those defaults and permit recursive/cache access.
• Access to the named-checkconf binary and the BIND configuration file.
• Access to the statistics channel (if configured) for traffic pattern analysis.
• Root or sudo access for configuration changes.
• An external host for testing recursion restrictions. Testing from localhost is insufficient because localhost is in the default ACL.

Procedure

Step 1: Audit the effective recursion ACLs

named-checkconf -p prints the effective configuration with all defaults expanded. This is the canonical way to see exactly which ACLs are in effect, including inherited values that do not appear in your config file.

# Check effective recursion and cache ACLs
named-checkconf -p /etc/named.conf 2>/dev/null | grep -i "allow-recursion\|allow-query\|allow-query-cache\|allow-recursion-on"

What to look for:

• allow-recursion { any; } means the resolver is open. Any host on the internet can use it for recursive lookups.
• allow-recursion { localnets; localhost; } is the default on modern BIND (9.4.1-P1+). Only local subnets and loopback can recurse.
• allow-query-cache inherits from allow-recursion if not explicitly set. An open allow-recursion implicitly opens cache access.
• allow-recursion-on is a separate interface gate. Both allow-recursion (address match) and allow-recursion-on (interface match) must be satisfied before recursion is permitted. Operators frequently miss this directive.

The coupling between allow-recursion and allow-query-cache is the most common source of confusion. If you set allow-recursion but leave allow-query-cache unset, the cache ACL inherits the recursion ACL value. This is usually correct, but it means changes to one silently affect the other.

allow-query defaults to { any; } and remains that way across all modern BIND versions. This is correct: authoritative queries should be answerable from any source. Only recursion and cache access need restriction.

Step 2: Check for views and split-horizon configurations

If your BIND deployment uses views, the recursion ACL must be checked per-view. A view that matches external clients (match-clients { any; }) with recursion yes; and allow-recursion { any; } is an open resolver, even if the internal view is properly restricted.

# Dump full effective config and review view structure
named-checkconf -p /etc/named.conf 2>/dev/null | grep -A50 "view\|match-clients\|allow-recursion"
# Increase the context count (or open the full dump in a pager) for long view/ACL blocks.

Split-horizon setups are the most common source of accidental open resolvers. The external view is often configured to serve authoritative data to the internet. If recursion yes; is inherited or set in that view, and the ACL is permissive, external clients get recursive access alongside the authoritative data.

Step 3: Detect amplification abuse patterns from traffic

If the resolver is or was open, check for signs of active amplification abuse. Attackers favor ANY and TXT query types because they produce the largest responses per query, maximizing the amplification factor.

# Check qtype distribution for amplification patterns
# Replace 8653 with your configured statistics-channel port
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); qt=d.get('qtypes',{}); \
  print('ANY:', qt.get('ANY',0), 'TXT:', qt.get('TXT',0))"

BIND opens no statistics channel unless statistics-channels is configured; when an inet entry omits its port, current BIND uses HTTP port 80. The example port below must match your configuration.

The normal DNS query mix is heavily A and AAAA. Elevated ANY or TXT query shares relative to baseline suggest amplification activity. A sustained ANY spike above 3x baseline warrants investigation.

Source-IP diversity is the other indicator. Amplification attacks use spoofed source IPs, so the set of client addresses is unusually broad and diffuse compared to your legitimate client base. BIND’s statistics channel does not expose per-source-IP breakdowns directly. Query logging or packet capture (tcpdump, dnscap) is needed for source analysis.

flowchart TD
    A["named-checkconf -p"] --> B{allow-recursion includes public ranges?}
    B -->|Yes| C{Intentionally public resolver?}
    B -->|No| D["Posture is restricted"]
    C -->|Yes| E["Expected: monitor for abuse"]
    C -->|No| F["Vulnerability: lockdown needed"]
    F --> G["Restrict ACLs"]
    F --> H["Enable rate-limit"]
    F --> I["Verify from external host"]
    E --> J["Check ANY/TXT share"]
    D --> J

Step 4: Test from an external source

The definitive test is to attempt a recursive query from a host that should not have access.

# From an external, unauthorized host (NOT localhost):
dig +time=2 +tries=1 @<resolver-ip> example.com A

If you get a valid answer (NOERROR with an A record), the resolver is open. If you get REFUSED, the ACL is working correctly. Always test from an actual external host, because localhost is typically in the localnets ACL and will succeed regardless of the external posture.

Lockdown

If the resolver should not be public, restrict the recursion ACL.

Define a named ACL containing only the subnets and hosts that should use this resolver for recursive lookups. Apply the same ACL to allow-query-cache explicitly, rather than relying on inheritance, to make the intent visible in the configuration and prevent coupling surprises.

Example configuration (place in named.conf, in the options block or the relevant view block):

acl "trusted-networks" {
    10.0.0.0/8;
    192.168.0.0/16;
    2001:db8::/32;
};

options {
    allow-recursion { "trusted-networks"; };
    allow-query-cache { "trusted-networks"; };
};

After changing the configuration:

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

# Apply without restarting (preserves cache)
rndc reconfig

rndc reconfig reloads the configuration without restarting the daemon.

Rate limiting as defense in depth

Even with proper ACLs, enabling Response Rate Limiting (RRL) provides defense in depth against amplification and volumetric abuse. RRL is opt-in: the default responses-per-second is 0, meaning no limit.

Example configuration:

options {
    rate-limit {
        responses-per-second 10;
    };
};

RRL drops or leaks a limited response to sources that exceed the rate threshold. The RateDropped and RateSlipped counters in BIND’s statistics track this activity. RateDropped counts responses dropped. RateSlipped counts leaked rate-limited responses: with a client cookie, a BADCOOKIE response carrying a server cookie; without one, a truncated response that prompts TCP retry. Sustained non-zero values during normal operation indicate either an active attack (RRL is working) or overly aggressive configuration affecting legitimate traffic.

Reducing amplification potential

If the resolver is intentionally public (you are operating a public recursive service), reduce the amplification factor that attackers can achieve:

• ANY queries produce the largest responses. BIND supports minimal-any yes; (added in stable BIND 9.10.8 and the 9.11 series), which limits ANY UDP responses to one matching RRset, reducing amplification without disabling recursion.
• Ensure DNSSEC validation is enabled. Modern BIND defaults dnssec-validation to auto; if your build was configured otherwise, audit the setting explicitly. DNSSEC-validated responses carry additional data that slightly increases response size, but disabling validation is not a valid amplification mitigation.

Verifying it works

After lockdown, verify from multiple vantage points:

# From localhost (should succeed):
dig +time=2 +tries=1 @127.0.0.1 example.com A

# From a trusted client subnet (should succeed):
dig +time=2 +tries=1 @<resolver-ip> example.com A

# From an unauthorized external host (should get REFUSED):
dig +time=2 +tries=1 @<resolver-ip> example.com A

Confirm the effective ACLs reflect the change:

named-checkconf -p /etc/named.conf 2>/dev/null | grep -i "allow-recursion\|allow-query-cache"

Check the BIND security log for denied recursive queries from external sources:

# Path varies by distribution; Debian/Ubuntu commonly use /var/log/named/security.log
# RHEL/CentOS typically log via syslog or journald
grep -i "denied\|refused" /var/log/named/security.log | grep -i "recursion\|query" | tail -20

On authoritative servers, some REFUSED responses from random internet sources are normal background noise. Random hosts probe for open recursion constantly. These denied entries indicate your ACL is working, not that you are under targeted attack.

Common pitfalls

• Forgetting allow-query-cache inheritance. Setting allow-recursion to a restricted ACL but leaving allow-query-cache unset means cache access inherits the restricted value. This is usually correct, but if someone later widens allow-recursion without checking allow-query-cache, the coupling produces unexpected results. Set both explicitly.

• Missing allow-recursion-on. This directive controls which interfaces accept recursive queries. Even with a correct address ACL, a permissive allow-recursion-on can expose recursion on interfaces intended only for authoritative data.

• Testing from localhost. Localhost is in the default localnets ACL. A successful recursive query from localhost tells you nothing about external posture. Always test from an external host.

• Rate limiting disabled by default. responses-per-second defaults to 0. Operators who assume BIND has built-in rate limiting for abuse mitigation are unprotected. RRL must be explicitly configured.

• Views hiding the exposure. In split-horizon deployments, the external view may have different ACLs than the internal view. Audit each view independently. A resolver that is properly locked down internally can still be open in the external view.

• Confusing REFUSED with SERVFAIL. REFUSED means the ACL denied the query. This is correct behavior for an unauthorized source. SERVFAIL means BIND tried to answer but failed internally. An open resolver being probed for amplification typically returns NOERROR (the query succeeds), not REFUSED.

Signals to monitor

How Netdata helps

• QType distribution over time. Netdata collects per-second qtype counters from BIND’s statistics channel. A sustained elevation in ANY or TXT query share is visible immediately, even when it is too small to move aggregate query rate.
• Response code breakdown. Correlating REFUSED, NOERROR, and SERVFAIL rates with qtype shifts helps distinguish amplification abuse (high NOERROR for ANY queries from many sources) from legitimate traffic pattern changes.
• RRL activity tracking. Netdata surfaces RateDropped and RateSlipped counters, making it clear when RRL is actively limiting responses and whether the rate corresponds to known traffic events.
• Query rejection rate. The RecQryRej counter tracks recursive queries rejected by ACL policy. A baseline of rejections from random internet sources is normal for a properly restricted resolver. Changes in the pattern after configuration changes confirm whether the ACL is working as intended.
• Incoming query rate correlation. Per-second query rate collected from Requestv4 and Requestv6 lets you distinguish a traffic spike (which could be amplification abuse) from a genuine capacity event, especially when correlated with qtype distribution.

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 dnssec-validation disabled: the security regression that ‘fixes’ 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 inline signing silently failed: missing keys and a zone served unsigned
• BIND journal (.jnl) corruption: dynamic-update and IXFR failures that block zone load