❓ Why does dig say connection timed out?

Step 1: Read what dig did#

side I am asking

Read the message and the exit status before changing anything.

dig +timeout=2 +tries=1 @192.0.2.1 example.com A; echo $?

;; communications error to 192.0.2.1#53: timed out

; <<>> DiG 9.18.39-0ubuntu0.22.04.6-Ubuntu <<>> +timeout=2 +tries=1 @192.0.2.1 example.com A
; (1 server found)
;; global options: +cmd
;; no servers could be reached
9

One communications error line per attempt, then the summary. The default is three tries at five seconds each, so a silent server costs fifteen seconds; +tries=1 +timeout=2 cuts it to two (dig(1)). Exit 9 is "No reply from server" on the same page. NXDOMAIN and SERVFAIL both exit 0.

192.0.2.1 hosts no nameserver: 192.0.2.0/24 is reserved for documentation (RFC 5737). The timeout is the right result, which makes this the control. An answer means something local is answering for every server you name, and nothing below holds. The interception check.

Name the server on every command below. dig reads /etc/resolv.conf on every run, and with no @ it takes its servers from there. What it takes from options depends on the build, with or without @: BIND 9.17.18 and later honour timeout: and attempts: when the command line gives neither (dighost.c), 9.16 and older read ndots: alone and keep the defaults above (the same file at 9.16.50). Measured on a silent server, dig 9.20.29, 2026-09-20: timeout:1 attempts:1 finished in 1 second, timeout:9 attempts:9 in 81. macOS ships 9.10, so run dig -v first.

$ dig @1.1.1.1 example.com A

The id, the Query time, the WHEN line and a cached TTL move between runs.

Step 2: Ask each leg and find the first one that is silent#

Ask each leg by address, in the order the query travels, and stop at the first silence.

$ dig @9.9.9.9 example.com A

check-a-resolver, then check-a-forwarder if that resolver forwards.

$ dig +timeout=2 +tries=1 @127.0.0.1 example.test SOA

$ dig -4 +norecurse @a.gtld-servers.net example.com NS

Then ask each address in that set, recursion off.

$ dig -4 +norecurse @hera.ns.cloudflare.com example.com SOA

A name resolves to more than one address, so -4 or -6 pins the family. The ;; SERVER: line names the address that answered. No terminal: ask for the same NS set in the dig tool.

Causes below, in the order the query travels.

Step 3: Check the one leg that is silent#

Check that one address, and nothing else on the network.

Three of dig's four non-answers brought no DNS message back. Only the fourth is a server talking.

The three non-answers, from a throwaway container:

$ dig +timeout=2 +tries=1 @127.0.0.1 example.test SOA
;; communications error to 127.0.0.1#53: timed out

; <<>> DiG 9.20.29-1~deb13u1-Debian <<>> +timeout=2 +tries=1 @127.0.0.1 example.test SOA
; (1 server found)
;; global options: +cmd
;; no servers could be reached

$ dig +timeout=2 +tries=1 @127.0.0.1 example.test SOA
;; communications error to 127.0.0.1#53: connection refused

; <<>> DiG 9.20.29-1~deb13u1-Debian <<>> +timeout=2 +tries=1 @127.0.0.1 example.test SOA
; (1 server found)
;; global options: +cmd
;; no servers could be reached

$ dig +tcp +timeout=2 +tries=1 @198.51.100.1 example.test SOA
;; Connection to 198.51.100.1#53(198.51.100.1) for example.test failed: network unreachable.
;; no servers could be reached

The first two are one command against one address: named running with blackhole { 127.0.0.1; }, then named stopped. They print different errors, which is the point. A server dropping this client looks like a packet filter dropping on the path, never like a closed port, because a closed port answers. The third address has no route at all.

Run both transports before calling a port shut. A server that answers over UDP and is silent over TCP is a real failure and I have no public capture of one: ten public resolver addresses checked from a clean vantage on 2026-09-20 answered over both. Reproduce it on a server you run with +tcp, then +notcp.

$ dig +timeout=2 +tries=1 @127.0.0.1 example.test SOA

Two BIND settings. allow-query refuses, so the client gets REFUSED; blackhole ignores the address, so the client gets the timeout above (BIND 9 ARM). Rate limiting is the third: with slip 0 an over-limit reply is dropped rather than sent truncated, and only the server's own counter names it.

$ rndc stats && grep -i "rate limit" /var/cache/bind/named.stats
                  12 responses dropped for rate limits

That one is intermittent by design, so it reads as a flapping server rather than a dead one.

Last, answer size. A big signed answer does not fit one UDP datagram, so the path has to carry a bigger one or carry TCP.

$ dig -4 +dnssec +bufsize=1232 +nocrypto +norecurse @a0.org.afilias-nst.info org DNSKEY

+nocrypto omits the key material and changes nothing on the wire; the reply is still 1319 bytes. RFC 1035 section 4.2.1 sets TC when a reply does not fit, and RFC 7766 section 1 makes TCP mandatory rather than a fallback, so a resolver does what dig just did. The client's UDP size rides in the OPT record's CLASS field (RFC 6891 section 6.1.2), and a client behind something that blocks fragments "SHOULD NOT choose a value that will cause fragmentation" (RFC 6891 section 6.2.3); DNS Flag Day 2020 put it at 1232. +bufsize=4096 was truncated on that server the same day, because it caps its own UDP at 1232 whatever the client asks. A path that eats fragments, or shuts TCP 53, breaks the big answers only.

side I am asking

One anycast address is many servers, so silence from this seat can be one instance. +nsid asks the server to name itself, where the operator publishes a name (RFC 5001).

$ dig +nsid @9.9.9.9 example.com A

See also#

• check-a-resolver, check-a-forwarder, check-a-delegation, check-an-auth: the four legs, one page each
• What does SERVFAIL mean?: the other failure, where a server did answer
• dig flags: +tries, +timeout, +tcp, +ignore, +bufsize and the rest
• DoT, DoH and DoQ: transports on a port nothing intercepts
• The dig tool: the same queries from a browser, and the trace from root