BIND Response Rate Limiting (RRL): RateDropped, RateSlipped, and throttled legitimate clients

You see sustained non-zero RateDropped or RateSlipped counters in BIND’s statistics channel. Either RRL is absorbing a real DNS amplification or flood attack, or the configuration is too aggressive and silently dropping or truncating responses to legitimate clients. BIND’s RRL counters do not distinguish attacker from legitimate client. A dropped response is a dropped response, whether the source was a spoofed botnet node or a real resolver. Telling the difference requires correlating the counters with traffic patterns, source IP distribution, and TCP reachability.

What this means

RRL is configured via a rate-limit {} block in named.conf, inside options or a view. It has been built into BIND since 9.9. When enabled, BIND maintains a token bucket per source prefix (IPv4 /24, IPv6 /56 by default) combined with the response name being served. Each response consumes a token. When the bucket goes negative, BIND applies rate limiting according to the slip parameter.

Two NSStats counters track the outcome:

• RateDropped: Responses silently dropped when the token bucket is negative and the response is not eligible for slipping. The client sees a timeout and may retry.
• RateSlipped: Responses sent with TC=1 instead of being dropped. The client is expected to retry over TCP.

The slip parameter controls the ratio of dropped to slipped responses:

The purpose of slipping is to give legitimate clients a recovery path: a real resolver that receives TC=1 retries over TCP. An attacker using spoofed source IPs cannot complete the TCP handshake, so amplification drops to near zero. If the request included a DNS COOKIE (RFC 7873), the slipped response is a BADCOOKIE error instead of a truncated response. Requests with valid server cookies bypass RRL entirely.

flowchart TD
    A[Query received] --> B{Token bucket
has credit?}
    B -->|Yes| C[Send normal response]
    B -->|No - over limit| D{slip setting?}
    D -->|slip 0| E[Silently drop
RateDropped++]
    D -->|slip >= 1| F{Eligible to slip?
every nth response}
    F -->|No| E
    F -->|Yes| G[Send TC=1 truncated
RateSlipped++]
    G --> H[Legitimate client
retries over TCP]
    H --> I{TCP/53 reachable?}
    I -->|Yes| J[Resolution succeeds]
    I -->|No| K[Resolution fails
silently]

RateDropped and QryDropped are separate counters. QryDropped also includes drops from fetches-per-zone, fetches-per-server, clients-per-query, and max-clients-per-query. Monitoring QryDropped alone cannot tell you whether RRL is the cause.

Common causes

Quick checks

# Check RateDropped and RateSlipped counters
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); ns=d.get('nsstats',{}); \
  print('RateDropped:', ns.get('RateDropped',0), 'RateSlipped:', ns.get('RateSlipped',0))"

# Check QryDropped to understand what fraction is RRL
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); ns=d.get('nsstats',{}); \
  print('QryDropped:', ns.get('QryDropped',0), 'RateDropped:', ns.get('RateDropped',0))"

# Check the rate-limit configuration
named-checkconf -p /etc/named.conf 2>/dev/null | grep -A 20 "rate-limit"

# Check incoming query rate and type distribution
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)); \
  ns=d.get('nsstats',{}); print('Requestv4:', ns.get('Requestv4',0), 'Requestv6:', ns.get('Requestv6',0))"

# Check TCP/53 reachability from a client perspective (run from a client subnet)
dig +tcp +time=2 +tries=1 @<server-ip> <your-zone> SOA

# Check tcp-clients limit and current TCP connection count
named-checkconf -p /etc/named.conf 2>/dev/null | grep "tcp-clients"
ss -tn state established '( sport = :53 )' | wc -l

# Check qps-scale if configured
named-checkconf -p /etc/named.conf 2>/dev/null | grep "qps-scale"

# Check BIND version (logging category for RRL events varies by version)
named -V | head -1

How to diagnose it

1. Confirm RRL is the source of drops. Compare RateDropped against QryDropped. If RateDropped accounts for most of QryDropped, the drops are RRL-related. If QryDropped is much larger, other mechanisms (fetches-per-zone, clients-per-query) are also dropping queries, which changes the diagnostic direction.

2. Determine whether the traffic is an attack. Check the incoming query rate against your baseline. A sudden spike concentrated on a few zones, with high source IP cardinality or elevated ANY/TXT query types, suggests an attack. A steady rate at normal volumes with RRL drops suggests misconfiguration.

3. Check whether responses-per-second matches your legitimate traffic profile. The limit applies per source prefix (default IPv4 /24, IPv6 /56). If a /24 containing many clients (a NAT egress, a container subnet, a corporate network) legitimately generates more queries per second than the limit, those clients will be throttled. The default responses-per-second is 0 (no limit), so any non-zero value was explicitly configured.

4. Verify TCP/53 reachability for slipped responses. If RateSlipped is non-zero, clients receiving TC=1 will retry over TCP. If TCP/53 is blocked by a firewall, constrained by tcp-clients, or otherwise unreachable, those retries fail silently. The client experiences resolution failure with no indication that RRL is the cause.

5. Check the _bind view if no explicit rate-limit is configured. BIND’s built-in CH class view may have RRL enabled by default. Monitoring tools that query hostname.bind, version.bind, or id.server can trigger drops from this built-in RRL. The counters will show non-zero RateDropped even though the operator never configured RRL.

6. Check qps-scale interaction. When total query rate exceeds qps-scale, BIND scales down the effective per-second limits proportionally: effective_limit = (qps-scale / current_qps) * configured_limit. During legitimate traffic spikes, this can cause unexpected throttling even when the configured limit appears adequate.

7. Determine whether the server is authoritative or recursive. ISC explicitly warns that RRL is intended for authoritative servers. On recursive resolvers, legitimate clients that repeatedly request the same domains (SMTP servers, HTTP clients, service discovery) can trigger rate limits. If your rate-limit block is in a view with recursion yes, consider whether RRL belongs there at all.

Metrics and signals to monitor

Fixes

If RRL is correctly absorbing an attack

Non-zero RateDropped during a confirmed attack is RRL working as designed. Do not raise limits in response. Instead:

• Verify that legitimate client subnets are in exempt-clients if they are being caught in the crossfire.
• Monitor TCP/53 capacity, as slipped responses will increase TCP load.
• Consider whether the attack volume warrants upstream filtering (RTBH, scrubbing) to reduce load on the DNS server itself.

If responses-per-second is too low

Raise the limit to accommodate peak legitimate traffic from the largest source prefix. A /24 behind NAT with 500 active users may generate hundreds of queries per second for popular domains. Set the limit above the 95th percentile of legitimate per-prefix QPS, with headroom for bursts.

If qps-scale is over-scaling

During legitimate traffic spikes, qps-scale can reduce effective limits below what is needed. Either raise qps-scale to match your peak legitimate QPS, or remove it if your traffic is bursty and the scaling behavior causes unpredictable throttling.

If TCP/53 is blocked or constrained

Slipped responses are only useful if clients can complete the TCP retry. Two failure modes:

• Firewall blocking TCP/53: The client receives TC=1, attempts TCP, and fails. Resolution fails silently. Fix the firewall rule.
• tcp-clients limit exhausted: Legitimate TCP connections plus attack connections fill the limit. Raise tcp-clients or filter abusive TCP sources.

If TCP cannot be made reliable, consider setting slip 0. This gives clients a clear timeout rather than a misleading TC=1 that promises TCP recovery that will fail.

If RRL is on a recursive resolver

Remove the rate-limit block from recursive views. ISC explicitly warns against using RRL on recursive servers because legitimate repeated queries for popular domains (CDN records, mail server lookups) will be throttled. RRL is designed for authoritative servers where the response set is fixed and amplification is the primary threat.

If the built-in _bind view is triggering

If monitoring tools query hostname.bind or version.bind frequently, the built-in _bind view’s RRL will drop responses. Options:

• Reduce monitoring query frequency for CH class queries.
• Configure monitoring tools to send DNS COOKIEs, which bypass RRL.
• Define a custom CH class view with different rate-limit settings.

Prevention

• Set responses-per-second based on measured legitimate traffic, not defaults or guesses. Sample peak per-prefix QPS during normal operation and set the limit above the 95th percentile with headroom.
• Test TCP/53 reachability from client subnets as part of routine health checks. Slipped responses depend on TCP being available. A firewall change that blocks TCP/53 silently breaks the RRL recovery path.
• Use exempt-clients for known high-volume sources: monitoring systems, load balancer health checks, internal resolvers that forward through this server.
• Do not enable RRL on recursive resolvers.
• Correlate RateDropped with attack indicators before tuning. Raising limits during an active attack defeats the purpose of RRL.
• Review qps-scale behavior against your traffic patterns. If your traffic is bursty, qps-scale may cause unpredictable throttling that looks like misconfiguration.
• RRL events are logged under the rate-limit category. If you rely on query-errors logging for monitoring, you may miss RRL events. Verify your logging configuration covers the rate-limit category.

How Netdata helps

• Per-second granularity on RateDropped and RateSlipped reveals the exact onset and offset of RRL activity, which cumulative counters obscure. Correlate RRL drops with query rate spikes or configuration changes in real time.
• QryDropped alongside RateDropped determines what fraction of total drops are RRL-related versus other mechanisms.
• Incoming query rate (Requestv4, Requestv6) correlated with RateDropped distinguishes attack-driven from configuration-driven drops. Rising query rate with rising RateDropped suggests an attack. Stable query rate with rising RateDropped suggests misconfiguration or qps-scale interaction.
• QType distribution (ANY, TXT) spikes alongside RRL activity signal amplification attacks, confirming that throttling is justified.
• TCP connection count monitoring catches the secondary failure mode where slipped responses push clients to TCP and TCP capacity is insufficient.
• ML anomaly detection flags the transition from zero to non-zero RateDropped/RateSlipped even when absolute counts are low, providing early warning before throttling affects a significant fraction of clients.

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