BIND UDP vs TCP query ratio: truncation, EDNS negotiation, and TCP fallback spikes

A rising TCP share of DNS queries is one of the most informative early warning signals in BIND. TCP normally carries under 5% of query volume on a recursive resolver. When that ratio shifts upward, something has changed in the resolution path: responses are being truncated, EDNS negotiation is failing, zone transfers are spiking, or a firewall is interfering with DNS traffic.

The shift matters more than the absolute count. A jump from 2% to 15% TCP share tells you the resolution path is under stress, regardless of total query volume.

What this means

DNS uses UDP for the vast majority of queries. TCP is reserved for zone transfers (AXFR/IXFR), responses too large for UDP, and explicit client requests over TCP. When BIND receives a truncated UDP response (TC bit set), it retries over TCP per RFC 7766. This is correct protocol behavior, but it has operational consequences.

Every TCP query consumes more resources: a file descriptor, TCP buffer memory, and a slot in the tcp-clients limit. When TCP share spikes, file descriptor usage rises, tcp-clients slots fill, and if TCP port 53 is blocked anywhere in the path, queries hang until timeout, consuming slots and FDs for the full timeout duration.

Since BIND 9.18, the default EDNS UDP buffer size dropped from 4096 to 1232 bytes, following the DNS Flag Day 2020 recommendation to avoid IP fragmentation. Large responses, especially DNSSEC-signed zones with many records, now truncate at 1232 bytes instead of fragmenting at 4096. The truncation triggers TCP fallback. This is intentional and safer than fragmentation, but operators upgrading from BIND 9.16 or earlier will see more TCP traffic for the same workload.

flowchart TD
    A["TCP ratio above baseline"] --> B{"Zone transfers active?"}
    B -->|Yes| C["Expected during refresh\nStagger schedules if excessive"]
    B -->|No| D{"Truncated counter elevated?"}
    D -->|Yes| E{"DNSSEC-heavy traffic?"}
    E -->|Yes| F["Large signed responses\nexceeding EDNS buffer"]
    E -->|No| G["Firewall stripping\nEDNS or fragments"]
    D -->|No| H{"EDNS0Fail elevated?"}
    H -->|Yes| I["EDNS negotiation\nfailure with upstream"]
    H -->|No| J{"Connection flood pattern?"}
    J -->|Yes| K["TCP SYN flood\nor slow loris"]
    J -->|No| L["Check Mismatch counter\nfor spoofed responses"]

Common causes

Quick checks

These commands assume the BIND statistics channel is configured on 127.0.0.1:8653. Adjust the host and port to match your statistics-channels block.

# Check current UDP/TCP query ratio from statistics channel
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); ns=d.get('nsstats',{}); \
  u=ns.get('QryUDP',0); t=ns.get('QryTCP',0); \
  print(f'UDP: {u} TCP: {t} TCP%: {t/(u+t+1)*100:.1f}%')"

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

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

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

# Check TCP connection count and FD pressure
ss -tn state established '( sport = :53 )' | wc -l
ls /proc/$(pgrep -x named)/fd | wc -l
grep "Max open files" /proc/$(pgrep -x named)/limits

# Test whether a DNSSEC response triggers truncation at 1232-byte buffer
# Substitute a DNSSEC-signed zone with large RRsets for a realistic test
dig @127.0.0.1 example.com A +dnssec +bufsize=1232 | grep -E "flags|tc"

# Check socket statistics for TCP/UDP patterns
curl -s http://localhost:8653/json/v1/server | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
  [print(f'{k}: {v}') for k,v in sorted(d.get('sockstats',{}).items())]"

How to diagnose it

1. Establish the baseline ratio. Sample QryUDP and QryTCP twice, 60 seconds apart, and compute the delta. Counters are cumulative since process start; only the rate of change matters. TCP share above 5% sustained is abnormal for most recursive resolvers.

2. Rule out zone transfers. Authoritative servers with many secondaries produce legitimate TCP bursts during refresh windows. Check transfer logs and SOA serial consistency between primary and secondaries. If transfers correlate temporally with the TCP spike, this is expected.

3. Check the truncation counter. The Truncated resolver stat tracks how often BIND received a truncated UDP response from upstream and retried over TCP. A spike here directly explains a TCP ratio increase. This is the strongest correlation signal.

4. Check EDNS negotiation failures. The EDNS0Fail resolver stat tracks EDNS(0) query failures. On certain upstream failures such as BADVERS or a FORMERR without an OPT record, BIND increments EDNS0Fail and retries without EDNS; a second failure marks that server as broken and moves on. If the upstream strips EDNS and TCP is also blocked, queries can end in SERVFAIL rather than a usable fallback.

5. Check whether a firewall is stripping EDNS OPT records or blocking UDP fragments. Test directly: send a query with a specific EDNS buffer size and check whether the response preserves the OPT record. If the resolver works locally but fails for specific upstream domains, suspect a firewall between the resolver and those authoritative servers.

6. Check tcp-clients and FD pressure. Elevated TCP ratio stresses the tcp-clients limit and file descriptor pool. Use rndc status to see current TCP client count against the limit. If tcp-clients is near its limit, legitimate TCP queries and zone transfers fail. CVE-2018-5743 fixes landed in BIND 9.11.6-P1, 9.12.4-P1, and 9.14.1. In those and later releases, effective limits include the TCP listener structures, so the reported count is not zero even with no active connections.

7. Rule out attack traffic. A TCP SYN flood produces many connections without corresponding query volume. Use ss -tan '( sport = :53 )' to inspect connection states. A flood shows many SYN_RECV or ESTABLISHED connections from diverse or spoofed source IPs with minimal actual query completion.

Metrics and signals to monitor

Fixes

Large DNSSEC responses (expected behavior)

If the TCP ratio increase correlates with elevated Truncated counters and the resolver handles DNSSEC-signed domains, this is the expected consequence of the 1232-byte EDNS buffer default. DNSSEC signatures add substantial data to responses, and large signed zones routinely exceed 1232 bytes.

Do not disable DNSSEC validation to reduce TCP traffic. Instead:

• Accept the TCP fallback as correct behavior. The 1232-byte default avoids IP fragmentation, which is unreliable and a security risk.
• If your network path reliably supports larger UDP payloads without fragmentation (clean path MTU above 1232), you can raise edns-udp-size in named.conf. This trades TCP overhead for fragmentation risk and should be validated per upstream path.
• Ensure TCP port 53 is open to all upstream authoritative servers. Blocked TCP makes truncation fatal instead of recoverable.

Firewall stripping EDNS or blocking TCP

If EDNS0Fail is elevated or queries for specific upstream domains fail intermittently, a firewall between your resolver and the authoritative server may be stripping EDNS OPT records, dropping UDP fragments, or blocking TCP port 53.

• Test EDNS path: dig @127.0.0.1 <domain> +dnssec +bufsize=1232 and check whether the response preserves the OPT record.
• Verify TCP port 53 is open outbound: dig @<upstream-ip> <domain> +tcp +time=2 +tries=1.
• RFC 9210 documents that when authoritative servers block DNS over TCP, truncated-and-then-blocked queries consume resolver resources until timeout, directly causing tcp-clients pressure and FD exhaustion.

Zone transfer bursts

TCP spikes during zone refresh windows are normal for authoritative servers with many secondaries. If the burst is problematic:

• Stagger zone transfer schedules across secondaries.
• Use IXFR instead of AXFR where possible (smaller transfers, less TCP time).
• Increase tcp-clients if legitimate transfer volume consumes available slots.
• Check for NOTIFY storms that trigger simultaneous transfer requests from many secondaries.

tcp-clients limit

If tcp-clients is exhausted by legitimate traffic:

• Increase the tcp-clients value in named.conf.
• Ensure the file descriptor limit (Max open files) is also raised. TCP clients and FDs are linked resources; raising one without the other creates a new bottleneck.
• On versions with the CVE-2018-5743 fix, effective tcp-clients accounting includes listener structures. Operators upgrading from older versions may need to increase the limit because the new accounting includes listeners.

TCP-based attacks

If the TCP spike is from a SYN flood or connection exhaustion attack:

• Apply RRL (rate-limit in named.conf) to throttle responses. Note that RateSlipped responses themselves cause TCP retries, so tune carefully.
• Use firewall-level SYN cookies or connection rate limiting on port 53.
• Restrict TCP access to known client ranges if the resolver does not need to accept TCP from all sources.

Prevention

• Monitor the UDP/TCP ratio as a trend, not a threshold. A resolver at 3% TCP that jumps to 8% is more interesting than one stable at 7%.
• Correlate truncation counters with TCP ratio. The Truncated resolver stat predicts QryTCP increases, giving a leading indicator before clients notice.
• Keep TCP port 53 open end-to-end. The most common preventable cause of TCP-related failures is a firewall that allows UDP/53 but blocks TCP/53.
• Verify FD limits are adequate. After any BIND upgrade or traffic growth, check that FD usage stays below 50% of the limit. The BIND files option is deprecated in BIND 9.18 and removed in BIND 9.20; FD limits must be controlled by the OS (ulimit, systemd LimitNOFILE).
• After upgrading from BIND 9.16 to 9.18+, expect more TCP traffic. The EDNS buffer default dropped from 4096 to 1232 bytes as part of DNS Flag Day 2020.

How Netdata helps

• The BIND collector captures QryUDP and QryTCP from NSStats, making the ratio visible as a per-second trend rather than a point-in-time counter snapshot.
• Netdata correlates TCP ratio with file descriptor usage from /proc/<pid>/fd, showing whether elevated TCP share is straining the FD pool.
• The Truncated and EDNS0Fail resolver stats are collected per-view. When Truncated rises in lockstep with QryTCP, the root cause is large responses, not an attack.
• RateSlipped and RateDropped from NSStats reveal whether RRL is actively truncating responses, distinguishing RRL-induced TCP from DNSSEC-induced TCP.
• ML anomaly detection flags unusual shifts in the TCP ratio even when the absolute value remains low.

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