❓ Why does dig say connection timed out?

A timeout means no reply came back at all: the server is unreachable or ignores the query, the port is filtered, or the path drops it. It is not a code DNS sends back, because a server that answers is never the cause of one (RFC 1035 section 4.1.1 has an RCODE for every case where a server does answer).

Step 1: Run the interception control#

side I am asking

Run a query at an address nothing can answer, and read what comes back.

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

192.0.2.0/24 is reserved for documentation (RFC 5737); nothing there runs a nameserver, so a timeout is the only correct result. Exit 9 is "No reply from server" (dig(1)); NXDOMAIN and SERVFAIL both exit 0, so the exit code alone tells silence from an answer. The default is three tries at five seconds each; +tries=1 +timeout=2 cuts a silent server's cost from fifteen seconds to two.

If this answers instead of timing out, something between this box and the network is intercepting port 53 and answering in the real server's place, and nothing below is trustworthy until that is fixed. Read the interception check.

Step 2: Ask a resolver you do not run#

side I am asking

Ask the same name and type at an address nothing here is configured to use.

$ dig @9.9.9.9 example.com A

The id, Query time, WHEN line and a cached TTL move between runs; that is normal.

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

Step 3: Check TCP and DoH#

Check the one leg that stayed silent in step 2 over TCP, then check this box's own network over DoH. A dropped UDP packet and a dead server both look silent under plain UDP; TCP to the same address tells them apart when it answers (RFC 7766 section 1). The DoH query goes to a public resolver by address, not to the silent leg and not through this box's resolver, so it only tests this box's HTTPS egress.

dig +tcp @ADDRESS NAME TYPE
curl -sS --max-time 5 -H 'accept: application/dns-json' 'https://1.1.1.1/dns-query?name=NAME&type=TYPE'

side I run the resolver

If you run the server, ask it on its own loopback, where the config decides the answer rather than the network.

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

Two BIND settings answer "up, but not to me" differently. allow-query refuses, so the client gets REFUSED; blackhole ignores the address, so the client gets the timeout above (BIND 9 ARM).

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 a port-53 interceptor cannot answer for
• The dig page: the same queries from a browser, and the trace from root