named not responding on port 53: total outage versus UDP-works-TCP-fails

named can be alive (pgrep -x named returns a PID) yet not answering on the serving interface. Process liveness checks pass, but clients experience timeouts and retries that propagate to every service depending on DNS.

Two diagnostic forks determine the fix path. The first: total outage (both UDP and TCP fail on the serving interface) versus UDP-works-TCP-fails. A total outage means the main DNS path is broken. A UDP-works-TCP-fails condition leaves large responses, DNSSEC-heavy answers, and zone transfers at risk while UDP-only health checks stay green. The second fork: loopback success versus serving-interface success. A query that succeeds against 127.0.0.1 confirms the daemon processes queries, not that real clients can reach it.

UDP carries standard queries and cache-served answers. TCP carries responses too large for UDP (truncated answers exceeding the EDNS buffer size), zone transfers (AXFR/IXFR), and DNSSEC-heavy responses with long signature chains. When TCP fails while UDP works, clients querying DNSSEC-signed zones receive truncated UDP answers and attempt TCP fallback. If TCP is blocked, the client sees a timeout or SERVFAIL. Zone transfers between primary and secondary nameservers use TCP exclusively; secondaries stop receiving updates and eventually serve stale data or expire the zone entirely.

Decision tree

flowchart TD
    A["pgrep -x named alive?"] -->|no| B["Process down: total outage"]
    A -->|yes| C["UDP dig @serving-ip?"]
    C -->|fails| D["TCP dig @serving-ip?"]
    C -->|works| E["TCP dig @serving-ip?"]
    D -->|also fails| F["Total outage: port not bound, firewall, or hung process"]
    D -->|works| G["UDP-only failure: check UDP-specific ACL or firewall rule"]
    E -->|fails| H["UDP-works-TCP-fails: FD exhaustion, tcp-clients limit, or TCP firewall"]
    E -->|works| I["Loopback OK: test from remote to rule out path, ACL, or view"]

Common causes

Quick checks

Run these in order. All are read-only and safe for production.

# Process liveness (use -x for exact match, not -f)
pgrep -x named

# Service status and restart count
systemctl is-active named
systemctl show named --property=NRestarts

# Listeners on port 53
ss -lunp '( sport = :53 )'
ss -ltnp '( sport = :53 )'

# UDP functional test (recursive resolver: probe a domain requiring recursion)
dig +time=2 +tries=1 @127.0.0.1 example.com A

# TCP functional test (recursive resolver)
dig +tcp +time=2 +tries=1 @127.0.0.1 example.com A

# Authoritative test (use a zone you serve, with +norecurse)
dig +time=2 +tries=1 +norecurse @127.0.0.1 <your-zone> SOA
dig +tcp +time=2 +tries=1 +norecurse @127.0.0.1 <your-zone> SOA

# Test from the serving interface IP, not loopback
dig +time=2 +tries=1 @<serving-ip> example.com A

# Control channel responsiveness (timeout means internal pressure)
timeout 5 rndc status

# File descriptor usage vs. limit
ls /proc/$(pgrep -x named)/fd | wc -l
grep "Max open files" /proc/$(pgrep -x named)/limits

How to diagnose it

1. Confirm the process is alive. Run pgrep -x named. Use -x (exact match), not -f, to avoid false positives on named-checkzone, named-checkconf, or similar binaries. If the process is gone, check dmesg for OOM kills and systemctl show named --property=NRestarts for restart loops.

2. Check whether port 53 is actually bound. Run ss -lunp '( sport = :53 )' for UDP and ss -ltnp '( sport = :53 )' for TCP. If no socket appears on the serving interface, named either failed to bind or is restricted by listen-on. On Ubuntu/Debian, systemd-resolved can bind to port 53 before named starts.

3. Test UDP on loopback. Run a role-correct query. For a recursive resolver, query a domain requiring recursion: dig +time=2 +tries=1 @127.0.0.1 example.com A. For an authoritative server, query a locally served zone with +norecurse. A REFUSED response means the ACL denied the query, not that the service is dead. A timeout means the listener is not processing.

4. Test TCP on loopback. Run the same query with +tcp. If UDP works but TCP fails, the problem is TCP-specific: FD exhaustion, the tcp-clients limit reached (150 by default in 9.16, 9.18, and 9.20), or a firewall rule blocking TCP/53.

5. Test from the serving interface IP. Repeat the UDP and TCP queries using the IP address that real clients use, not 127.0.0.1. If loopback works but the serving IP fails, the problem is in the network path, firewall, ACL, or view configuration.

6. Test from a remote host. Run dig from an external machine targeting the serving IP. If local tests work but remote tests fail, the firewall, routing, or network ACL is blocking traffic. Use IP addresses, never a hostname that depends on the server under test, to avoid circular dependencies.

7. Classify the failure. Use the decision tree to categorize the result and determine the fix path.

Metrics and signals to monitor

Fixes

named not running or crash-looping

If the process is gone, check dmesg | grep -i oom for OOM kills. If OOM is the cause, configure max-cache-size to a safe value before restarting. If the process is crash-looping, check recent logs for assertion failures or fatal errors: journalctl -u named --since "10 min ago". Do not restart as a first fix without understanding why it stopped.

Port 53 not bound

If named is running but no socket appears on port 53, check for a port conflict. On systems with systemd-resolved, it may bind to port 53 before named starts. Check with ss -lunp '( sport = :53 )' to identify what holds the port. If listen-on is configured, verify it includes the serving interface address. A missing or overly restrictive listen-on directive causes named to bind only to loopback.

Firewall or network ACL blocking

If loopback works but remote queries fail, inspect firewall rules. Check iptables -L -n or nft list ruleset for rules affecting port 53. Verify that both UDP and TCP are allowed. A common pattern is UDP/53 open but TCP/53 blocked, which produces the UDP-works-TCP-fails symptom. Also check upstream firewalls, cloud security groups, and network ACLs outside the host.

BIND ACL denial (REFUSED)

A REFUSED response means the ACL denied the query, not that the service is dead. Check allow-query, allow-recursion, allow-query-cache, and view match-clients in named.conf. Use named-checkconf -p /etc/named.conf to see the effective configuration. Correct the ACL to include the client subnet.

BIND 9.20.0 changed the default allow-transfer value from { any; } to { none; }; explicit outbound transfer ACLs are therefore required on 9.20 secondaries that previously worked on 9.18.

TCP-specific failure (FD exhaustion or tcp-clients limit)

If UDP works but TCP fails, check two things. First, count open file descriptors: ls /proc/$(pgrep -x named)/fd | wc -l against the limit in /proc/<pid>/limits. FD exhaustion causes BIND to silently drop queries and fail to accept new TCP connections. Increase the OS-level limit via systemd LimitNOFILE or ulimit.

Do not rely on the BIND files option for this: it remains available in 9.16 and 9.18, but BIND 9.20.0 removed files (along with coresize, datasize, and stacksize) and recommends enforcing limits externally with ulimit or a process supervisor such as systemd.

Second, check concurrent TCP connections against the tcp-clients limit (150 by default in 9.16, 9.18, and 9.20). Use ss -tan '( sport = :53 )' to count established connections. If legitimate traffic is exhausting the limit, raise it and ensure FD headroom scales accordingly.

View or split-horizon mismatch

If some clients work and others fail, examine view configuration. Views are evaluated in order, and a client may match the wrong view or no view at all. Check match-clients and the ordering of view blocks in named.conf. Test with dig from a source IP that represents the failing client subnet to reproduce the issue.

Prevention

• Monitor both transports separately. A UDP-only health check will not catch TCP failures. Test both with role-correct canaries.
• Monitor from the serving interface, not just loopback. Loopback success hides firewall, ACL, and view problems. Test against the IP that real clients use.
• Use IP addresses for monitoring targets, never hostnames. A monitoring check that resolves the DNS name of the server under test creates a circular dependency.
• Track file descriptor usage as a percentage of the limit. FD exhaustion is cliff-edge and silent. Alert above 70%.
• Verify zone loads after every rndc reload. named starts successfully even if zones fail to load. A post-reload check catches silent failures.
• Define sustained failure as 3+ consecutive failures over 2-5 minutes. A single timeout may be transient packet loss. Sustained failure is actionable.
• Use pgrep -x named, not pgrep -f named. The -f flag matches named-checkzone, named-checkconf, and other binaries, producing false positives.

How Netdata helps

• Per-second UDP and TCP query counters let you see the moment one transport degrades while the other stays healthy. Correlating the divergence with FD usage and TCP connection count isolates the cause.
• Process liveness and restart count are tracked continuously. A crash-loop that passes a periodic liveness check is visible as a climbing NRestarts counter.
• File descriptor monitoring surfaces FD exhaustion before it becomes silent query drops. Correlating FD count with TCP failures and query drops confirms the cause.
• Kernel UDP receive buffer errors (UdpRcvbufErrors from /proc/net/snmp) catch packet loss that BIND never sees. If queries are disappearing but BIND’s counters show nothing, kernel drops are the likely cause.

Related guides

• How BIND actually works in production: a mental model for operators
• BIND monitoring maturity model: from survival to expert
• BIND SERVFAIL responses: what a DNS SERVFAIL actually means and how to trace the cause