DNS lookups take 5 seconds (timeout then retry) Networking Origin: Network OSI layer 7 · Application Last updated 5 Nov 2026

Networking: Every connection pauses about 5 seconds — resolv.conf nameserver timeout, then fallback to the next DNS server

The first DNS server in the list isn't answering, so each lookup waits out a timeout before trying the next one.

Exact message you may see DNS lookups take 5 secondsresolv.conf timeout 5 secondsslow DNS resolution 5 second delay;; connection timed out; trying next originDNS timeout then fallback to second nameserver
Explore the map of this error Full error map →
Seen on: Linux Kubernetes Networking

Meaning

The default resolver timeout is 5 seconds per server. Put working resolvers first, remove dead entries, and test with dig @server name. The 5-second pattern also appears when A and AAAA queries race, or when conntrack drops DNS packets (a known Kubernetes issue).

Common causes

  • Dead or unreachable first nameserver in resolv.conf
  • Firewall dropping DNS to one resolver
  • AAAA/A parallel query race with conntrack
  • VPN pushing unreachable DNS servers
  • Resolver overloaded

⚡ Quick fix

  1. Test each: dig @10.0.0.2 example.com
  2. Reorder or remove dead nameservers
  3. Set options timeout:1 attempts:2 and single-request-reopen where needed

Detailed fix by platform

Linux

  1. bash
    cat /etc/resolv.conf
time dig @10.0.0.2 example.com +tries=1 +time=2

How to diagnose

  1. Nameservers — All responding?
  2. Delay — Exactly ~5 s?
  3. Conntrack/VPN — Involved?

🔧 Still not fixed?

Many errors look alike. If the steps above didn’t solve it, one of these is probably what you’re facing:

Where this error sits

Origin: Network. Errors that are often confused with or caused by this one (click to open):

dig: status: REFUSED (recursion not available) — Networking: dig: status: REFUSED / recursion requested but not available — the DNS server won't resolve queries for you (Networking)dig: status: REFUSED …dig: status: SERVFAIL (DNSSEC validation failed) — Networking: dig: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL — resolver failed to answer (DNSSEC validation or upstream failure) (Networking)dig: status: SERVFAIL…DNS in pod — DNS not working inside a Kubernetes pod (could not resolve host / nslookup: can't resolve) (Kubernetes)DNS in podDomain still resolves to the old IP (DNS propagation/cache) — Networking: DNS changed but the domain still resolves to the old IP — TTL and resolver caching ("propagation") (Networking)Domain still resolves…Internal hostnames fail on VPN (split DNS / systemd-resolved) — Networking: VPN connected but internal names like db.corp.local don't resolve — split DNS / 127.0.0.53 stub resolver not using the VPN DNS (Networking)Internal hostnames fa…IPv6 enabled but broken: slow connections / Happy Eyeballs — Networking: Sites load slowly or hang for seconds — broken IPv6 (AAAA resolves, IPv6 route missing) falling back to IPv4 (Networking)IPv6 enabled but brok…nc/telnet hangs: firewall DROP vs REJECT — Networking: nc -vz hangs then times out — firewall silently DROPs packets (REJECT would answer "Connection refused") (Networking)nc/telnet hangs: fire…nf_conntrack: table full, dropping packet — Networking: kernel: nf_conntrack: table full, dropping packet — new connections fail on a Linux firewall/NAT host (Networking)nf_conntrack: table f…DNS looku…

Explore the map of this error Full error map →

🧠 Still stuck? Analyze your error

Paste the full message, response headers or stack trace — we'll detect the platform and point to the most likely cause.

💬 What worked for others

No tips yet — did something else fix this for you?

Share what worked for you

Tips are checked by an editor before they appear. Links are removed.