$ guides / bind-dns ▌

BIND DNS · OPERATIONS PLAYBOOK

BIND fails quietly: a recursion limit that SERVFAILs everyone, signatures that expire worldwide, and queries the kernel drops before named ever counts them

A single named daemon that is a recursive resolver, an authoritative server, and a DNSSEC validator at once — with a hard recursive-clients ceiling, a cache that can spiral, secondary zones that quietly expire into SERVFAIL, and its most dangerous failure invisible to its own statistics. We trace how the daemon behaves under load, where throttling turns into outage, and what to do when it does.

> Start with the monitoring checklist → # Jump to the full guide list

BIND's defaults get you resolving in minutes, then hand you a set of cliff-edges that most teams only meet during an incident.

The defaults work. Until an upstream nameserver slows down, every recursive query holds a recursive-clients slot for the full timeout, the table fills, and BIND returns SERVFAIL to everyone — including names whose own upstreams are perfectly healthy. Until a secondary loses contact with its primary, the SOA expire timer runs out, and the zone vanishes into SERVFAIL after days of quietly serving stale-but-working answers. Until the system clock drifts five minutes and DNSSEC validation starts rejecting half the signed internet. Until an inline-signed zone's key file goes missing — no log error, no .signed.jnl — the signatures expire, and validating resolvers worldwide reject your domain while your own server serves it happily. Until the kernel's UDP receive buffer overflows and drops queries before named ever sees them: no log, no counter, nothing.

These guides are written for engineers who already run BIND, not for people learning what a DNS record is. The goal is the mental model of how the daemon actually behaves under load across its recursive and authoritative roles, the failure patterns that keep recurring, the monitoring story that catches them before they page anyone, and the runbooks you wish someone had handed you before your last incident.

How BIND actually runs in production

BIND is not just a resolver. It is one named daemon that can be a recursive resolver, an authoritative server, and a DNSSEC validator at the same time, driving every query through a pipeline of policy, cache, recursion, and zone lookup on a pool of per-core worker threads. Most production failures live between these layers — and on a mixed-role server, recursive and authoritative signals mask each other in the aggregate.

clients + transport

UDP and TCP on port 53. netmgr reads packets off the sockets; ~95% of normal traffic is UDP, with TCP for large answers, DNSSEC, and zone transfers. Every inbound TCP connection and every outbound recursive fetch costs a socket and a file descriptor.

INGRESS

ACLs + views

<code>allow-query</code>, <code>allow-recursion</code>, and <code>allow-query-cache</code> decide whether a client is answered or gets REFUSED. Split-horizon views select a different cache and zone set per client — the source of every "works from here, fails from there" report.

POLICY

cache (recursive views)

An in-memory answer cache with TTL-based expiry, bounded by <code>max-cache-size</code> and LRU-evicted under pressure (<code>DeleteLRU</code>). A falling hit ratio is the leading edge of recursive pain: more misses mean more outbound work and more exposure to upstream trouble.

CACHE

recursive resolver + ADB

Cache misses become outbound fetches. Each one holds a slot in the <code>recursive-clients</code> table for up to the resolver timeout, and the address database tracks upstream RTT for server selection. This table is BIND's circuit breaker — when it fills, new recursive queries get SERVFAIL.

RESOLVE

authoritative zones

Zone data lives in memory (RBT), with journals for dynamic updates and AXFR/IXFR transfers driven by SOA serials and timers. A secondary keeps serving the last transfer until the <code>expire</code> timer fires, at which point it removes the zone and SERVFAILs it.

AUTHORITY

DNSSEC engine

Validates answers in recursive mode (CPU-heavy and acutely clock-sensitive) and signs zones in authoritative mode with inline signing. The catch: an authoritative server never validates its own signatures, so it will serve expired ones without noticing.

DNSSEC

netmgr workers + CPU

One libuv worker thread per core handles I/O and query processing. A single hot core can bottleneck the whole daemon while aggregate CPU still looks idle — DNSSEC crypto, large zone loads, and malformed-packet parsing are the usual drivers.

WORKERS

kernel packets + descriptors

UDP receive buffers, file descriptors, and sockets sit below named. The kernel silently drops overflow packets before named ever reads them, and the OS FD limit caps everything above — the daemon's worst failures are the ones its own statistics cannot see.

KERNEL

Why this matters: 'DNS is slow' or 'queries are failing' can come from one slow upstream filling the recursive-clients table, a cache spiralling under memory pressure, a secondary zone that quietly expired, DNSSEC validation breaking on a clock skew, a single saturated core, or packets the kernel dropped before named ever counted them. The symptom rhymes, but each layer has a different signal — and a different fix.

The failures you'll actually see

Most BIND incidents fall into a small set of recurring patterns. Recognise the shape, and triage gets dramatically faster.

CRITICAL

The recursion cascade

One upstream nameserver slows down or goes unreachable. Every recursive query bound for it holds a recursive-clients slot for the full timeout (default 10s, up to three retries), slots fill, and BIND starts returning SERVFAIL for all recursive queries — even those bound for perfectly healthy upstreams. The resolver becomes collateral damage from a single upstream failure, and CPU can stay moderate because the worker threads are blocked waiting, not computing.

no more recursive clients: quota reached in the logs
RecursClients at or near the recursive-clients limit
Broad SERVFAIL across many unrelated domains, not one zone
rndc recursing shows most fetches waiting on the same upstream

Investigate →

CRITICAL

The DNSSEC time bomb

DNSSEC validation starts failing while unsigned domains keep resolving. Because so much of the internet is signed (.com, .org, google.com), the impact is widespread but not total. The usual cause is local, not upstream: the system clock has drifted past the RRSIG validity window, or the managed-keys trust anchor is stale after a KSK rollover. dig +cd resolves; a plain dig SERVFAILs — the tell that validation is the problem.

broken trust chain resolving in the logs
ValFail climbing across many unrelated signed domains
dig +cd succeeds where a plain dig returns SERVFAIL
Clock offset elevated (NTP failure) around the same time

Investigate →

IMMINENT

The silent zone expiry

A secondary cannot reach its primary — a firewall change, a decommissioned primary, a rotated TSIG key. Transfers fail, but nothing breaks yet: the secondary serves the last transfer for the entire SOA expire duration, wrong-but-functional, for hours or days. When the timer hits zero it removes the zone and returns SERVFAIL for it — a cliff-edge after a long, quiet grace period. Only that zone is affected, so process health stays green throughout.

SOA serial on the secondary stuck behind the primary
rndc zonestatus shows the expire countdown shrinking
Zone-transfer failures in the xfer-in log
SERVFAIL for one specific zone once expire hits zero

Investigate →

CRITICAL

The memory wall and OOM restart storm

named's memory grows — an unbounded cache, an oversized RPZ dataset, or a version-specific leak — until the kernel OOM killer terminates it and DNS goes fully dark. If systemd restarts it, the cold cache serves at a 0% hit ratio and every query triggers recursion, hammering upstreams in a warming storm. If the memory condition persists, the cycle repeats. BIND also holds RSS after peaks (allocator fragmentation), which fools naive memory alerts.

dmesg shows the OOM killer selected named
systemctl NRestarts on named incrementing
Cache hit ratio at 0% and upstream query rate spiking after a restart
RSS climbing with no explicit max-cache-size set

Investigate →

ACTIVE

The invisible packet loss

The host can't process packets fast enough, so the kernel drops them at the UDP receive buffer before named ever reads them. DNS degrades as random client timeouts and retries — usually misdiagnosed as an upstream problem — while named's own statistics show nothing wrong, because it only counts queries it managed to read. Bandwidth often has plenty of headroom: this is a packets-per-second and single-core limit, not a throughput one.

UdpRcvbufErrors in /proc/net/snmp climbing
Sustained non-zero Recv-Q on the port 53 UDP socket
softirq / system CPU high, often pinned to one core
Clients report timeouts while BIND logs stay clean

Investigate →

ACTIVE

The water torture flood

Attackers query random subdomains of a target — a1b2c3.victim.com — so every name is unique, the cache is useless, and each query forces a fresh recursion. RecursClients climbs, NXDOMAIN and CPU spike, and resolution degrades for all clients, not just the targeted domain. The distinguishing mark is query-name cardinality: a flood of never-repeated names concentrated under one parent domain.

NXDOMAIN spiking, concentrated on one parent domain
CacheMisses spiking with near-zero name repetition
RecursClients climbing toward the limit
CPU elevated with no matching rise in cache hits

Investigate →

Choosing a tool

Best BIND DNS Monitoring Tools: 10 Ranked for 2026

A ranked review of the tools teams actually shortlist here, what each one is genuinely good at, and how the pricing behaves as you scale.

Read the buyer's guide →

BIND monitoring maturity levels

BIND observability works in four practical levels. Each is a complete operation, not a stepping stone. Pick the level that matches how much your DNS matters. Most production resolvers and authoritative servers should land at the second level.

Level 1: Survival

Know that something is wrong

Survival monitoring is the floor. With these signals you can answer one question: is named alive and answering, on the transport and in the role you actually serve? You will not learn what broke, but you will learn that something broke before users do. Survival is enough for dev servers and non-critical zones.

Process + role-correct canary pgrep -x named, plus a dig that exercises the role (recursive name, or +norecurse SOA).
UDP query answers The main path — a role-correct query returns over UDP.
TCP query answers Large answers, DNSSEC, and zone transfers all need working TCP.
Process memory (RSS) RSS not climbing toward a system or cgroup limit.

Level 2: Operational

Diagnose most incidents on your own

Operational monitoring is what most production servers should target. Survival tells you something is wrong; operational tells you what. With this coverage your team can usually diagnose an incident on its own: recursion pressure, cache decay, resource limits, DNSSEC failures, and secondaries drifting toward expiry.

Incoming query rate Requestv4 + Requestv6; a sudden drop is a listener or network fault.
SERVFAIL rate (% of responses) The single most important error signal; normal is near zero.
RecursClients (% of limit) BIND's recursive circuit breaker; watch past 50% of the limit.
Cache hit ratio A sustained drop from baseline is the start of recursive pain.
File descriptor usage (%) Cliff-edge: at the limit named drops queries and transfers silently.
SOA serial + expire runway For secondaries: are transfers keeping the zone alive?
DNSSEC validation failures (ValFail) Broad ValFail usually means a local clock or trust-anchor fault.
Zone load health after reload named keeps running even when a zone fails to load — verify it.

Level 3: Mature

Catch problems before they become incidents

Mature monitoring catches problems before they wake anyone up. Upstream RTT creeping, timeouts and lame delegations rising, the kernel starting to drop packets, TCP connections accumulating, the cache thrashing. None of these page you on day one. They become page-out incidents on day thirty.

Resolver RTT distribution Outbound RTT to upstreams (QryRTT* per view) shifting to high buckets.
Resolver failure counters QueryTimeout and Lame per view localise a broken upstream or delegation.
UDP RcvbufErrors (kernel drops) Invisible to BIND; the #1 cause of 'queries disappearing'.
Response-code breakdown NXDOMAIN and REFUSED tracked individually, not just SERVFAIL.
TCP connections + tcp-clients Headroom before the TCP limit refuses transfers and fallback.
Cache eviction (DeleteLRU) Rapid LRU eviction means the cache is full and thrashing.
RRL + RPZ activity RateDropped / RateSlipped and RPZRewrites — attack and interception signals.
Control-plane responsiveness rndc slow or dead cripples incident response before queries fail.

Level 4: Expert

Reactive instrumentation after real incidents

Expert signals enter your stack the day after a specific incident proved you needed them. Per-core saturation, cache-memory internals, RRSIG expiry, query-name entropy, clock offset, signing freshness. Most teams never need every signal here. Add the ones your incident history says you do.

Per-core CPU + softirq imbalance One pinned core while aggregate CPU looks idle (no per-thread BIND stat).
rndc recursing sampling Which upstreams the in-flight fetches are waiting on, during an incident.
Cache memory internals TreeMemInUse / HeapMemInUse / CacheNodes — where the RAM is going.
RRSIG expiry on signed zones The server won't tell you; expired signatures are a worldwide outage.
Query-name entropy A flood of never-repeated names is a water torture attack.
NTP clock offset A DNSSEC leading indicator; drift breaks validation minutes later.
Source-port entropy porttest.dns-oarc.net — cache-poisoning resistance for resolvers.
Inline signing freshness Absence of .signed.jnl is the only sign a zone silently went unsigned.

Operating mistakes worth avoiding

The traps BIND teams keep falling into. Each has a clear, well-known fix. Most teams only learn it after an incident.

Not monitoring kernel-level UDP drops

The single most systematic gap in DNS monitoring. BIND only counts queries it read from the socket — queries the kernel drops on receive-buffer overflow are invisible: no log, no counter, nothing. The only evidence is <code>UdpRcvbufErrors</code> in <code>/proc/net/snmp</code>. Teams discover this mid-incident, having dropped queries for hours while 'BIND looked fine'. Monitor it, and raise <code>net.core.rmem_max</code> when it fires.

Treating DNS as a binary up/down check

Most monitoring asks 'can I resolve a query?' and stops. That misses every degradation: rising latency, a declining cache hit ratio, creeping SERVFAIL, resource limits approaching. A BIND server can be slowly dying for days while passing a binary check — and the binary check is exactly what a load balancer or uptime probe gives you.

Ignoring the recursive-clients limit

This is BIND's circuit breaker. When it trips, every recursive query gets SERVFAIL, and teams that watch query rate and latency but not in-flight recursive count see the outage with no idea of the cause. Watch <code>RecursClients</code> as a percentage of the limit — the soft quota at 90% (default 900) starts rejecting before the hard limit (1000).

Not tracking SOA serial consistency and expire runway

Zone-transfer failures are silent and time-delayed. A secondary serves stale data for days until the <code>expire</code> timer runs out, then suddenly SERVFAILs the whole zone. A serial comparison catches the drift within minutes; even fewer teams track the expire countdown — and the countdown, not the serial mismatch, is the actual outage clock.

Running with the default file-descriptor limit

The default <code>ulimit -n</code> of 1024 is far too low for a busy recursive resolver — production wants 65536 or more. At the limit, named cannot open new sockets and drops queries silently or fails transfers, often misdiagnosed as a disk problem. It works fine under low load and fails exactly when you need it. Note the <code>files</code> option is gone in 9.20 — set OS/systemd limits.

Leaving query logging on in production

Teams enable query logging to debug something, then forget it. At high QPS the log I/O becomes the bottleneck — a 50k-qps resolver can emit over a gigabyte an hour — and the slowdown is so gradual it gets blamed on 'traffic growth'. Disable it in production; if you need query visibility, sample with dnstap instead.

Not monitoring RRSIG expiry on zones you sign

Inline signing can fail silently: a missing key file produces no log error and no <code>.signed.jnl</code>. The authoritative server keeps serving because it never validates its own signatures — but once they expire, validating resolvers worldwide reject the zone. This is not exposed in the statistics channel; it needs an external check of the RRSIG validity window.

Monitoring mixed-role servers in aggregate

A server that is both recursive and authoritative reports one set of numbers, and recursive traffic noise buries zone-specific authoritative failures. A zone that failed to load or a stale secondary hides behind healthy recursion stats. Monitor per-view, and verify zone load after every <code>rndc reload</code> — the error is logged once and never read again.

BIND runbooks in this section

Each guide is a focused runbook for one symptom or topic. Pick one when you have an incident, or use the categories to learn the area.

▸

Start here

▸

Availability, SERVFAIL, and REFUSED

▸

Recursion and the recursive-clients limit

▸

Upstream nameservers and RTT

▸

Cache efficiency and pressure

▸

Zone transfers, serials, and expiry

▸

Zone loading, reloads, and updates

▸

DNSSEC validation and signing

▸

Packet processing, protocol, and descriptors

▸

Memory, CPU, and logging

▸

Rate limiting, RPZ, and abuse

WHERE TO GO NEXT

Setting up BIND monitoring, or putting out a fire?

If you're starting from scratch, the monitoring checklist is the path of least regret. If you're mid-incident, jump straight to the symptom that matches what you're seeing.

> Start with the checklist > Back to Operations Guides