{"id":1209,"date":"2026-09-23T23:06:27","date_gmt":"2026-09-23T23:06:27","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1209"},"modified":"2026-09-23T23:06:27","modified_gmt":"2026-09-23T23:06:27","slug":"diagnosing-dns-resolver-latency-vps-dig-tcpdump","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/diagnosing-dns-resolver-latency-vps-dig-tcpdump\/","title":{"rendered":"Diagnosing DNS Resolver Latency on a VPS with dig and tcpdump"},"content":{"rendered":"\n

DNS resolution latency is invisible until it is not. A resolver that answers in 5 ms and one that answers in 2 seconds produce identical application code and wildly different page load times. Because the delay appears in name lookups rather than in your database or PHP, it hides from application profiling. This guide shows how to measure resolver latency directly, find the slow path, and tune the settings that cause it.<\/p>\n\n\n\n

Measure resolver latency directly<\/h2>\n\n\n\n

dig<\/code> reports query time in its footer. Run several lookups against your configured resolver and against a public one to isolate local configuration from upstream latency.<\/p>\n\n\n\n

dig +stats example.com @127.0.0.53 | grep -i \"Query time\"\ndig +stats example.com @1.1.1.1 | grep -i \"Query time\"<\/code><\/pre>\n\n\n\n
A large gap means the problem is local \u2014 the stub resolver, the resolving library, or ndots<\/code> behaviour. A uniformly slow result on both means upstream latency.<\/p>\n\n\n\n
Understand the ndots search-path trap<\/h2>\n\n\n\n
The default ndots:1<\/code> means any name with fewer than one dot in it is tried against every search domain before being tried as absolute. With two search domains, api<\/code> becomes two failed lookups followed by the real one \u2014 up to three round trips where one should do. For applications resolving many short internal names, this multiplies latency.<\/p>\n\n\n\n
# \/etc\/resolv.conf\noptions ndots:2 timeout:1 attempts:2 rotate\nnameserver 127.0.0.53<\/code><\/pre>\n\n\n\n
Raising ndots<\/code> to 2 means names with fewer than two dots skip the search list. Use a fully-qualified name with a trailing dot (api.internal.example.com<\/code>) when you want no search expansion at all.<\/p>\n\n\n\n
Trace where the time actually goes<\/h2>\n\n\n\n
When dig<\/code> is fast but the app is slow, capture the resolver traffic and read the timings. tcpdump<\/code> on port 53 shows whether a query is retried, duplicated, or sent to a second nameserver after a timeout.<\/p>\n\n\n\n
tcpdump -ni any -ttt port 53 -c 20<\/code><\/pre>\n\n\n\n
The -ttt<\/code> flag prints the delta between packets. A repeated query to a second nameserver followed by a long gap is the classic signature of the primary resolver timing out and the client failing over. Reducing timeout<\/code> and attempts<\/code> in resolv.conf shortens that worst case.<\/p>\n\n\n\n
Run a local caching resolver<\/h2>\n\n\n\n
A local resolver caches answers in memory and answers repeat lookups without network round trips. On a VPS, a small caching resolver bound to the loopback interface turns a 30 ms upstream lookup into sub-millisecond cache hits. Point \/etc\/resolv.conf<\/code> at it and let it forward.<\/p>\n\n\n\n
# after installing a local resolver\n# \/etc\/resolv.conf\nnameserver 127.0.0.1\noptions ndots:2 timeout:1 attempts:2<\/code><\/pre>\n\n\n\n
Signal<\/th>Meaning<\/th>Action<\/th><\/tr><\/thead>
dig slow, public DNS fast<\/td>Local stub\/library issue<\/td>Check ndots and stub config<\/td><\/tr>
Both slow<\/td>Upstream latency<\/td>Use a closer\/caching resolver<\/td><\/tr>
tcpdump shows retries<\/td>Timeouts and failover<\/td>Lower timeout\/attempts<\/td><\/tr>
First query slow, rest fast<\/td>Cold cache<\/td>Expected; keep resolver warm<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Test the resolver the way the application does<\/h2>\n\n\n\n
dig<\/code> is a clean-room test; your application uses the system resolver through getaddrinfo<\/code>, which obeys \/etc\/nsswitch.conf<\/code> and the search list. Reproduce the application’s path so you measure what it actually experiences, including any hosts-file lookup and any search-domain expansion.<\/p>\n\n\n\n
getent ahosts example.com\ngetent ahosts api\nstrace -f -e trace=sendto,recvfrom -T getent ahosts api 2>&1 | head -30<\/code><\/pre>\n\n\n\n
The -T<\/code> flag prints the time spent in each syscall. If the same name produces several sendto<\/code> calls with multi-second gaps between them, you have found the retry-and-failover path that application-level profiling never shows.<\/p>\n\n\n\n
Pick the right resolver for the workload<\/h2>\n\n\n\n
Workload<\/th>Resolver choice<\/th>Reason<\/th><\/tr><\/thead>
Single web server<\/td>Local caching resolver on 127.0.0.1<\/td>Sub-ms cache hits, no extra hosts<\/td><\/tr>
Many containers<\/td>Host resolver + container DNS forwarding<\/td>One cache shared across namespaces<\/td><\/tr>
Inside a private network<\/td>Local resolver forwarding to internal DNS<\/td>Split-horizon names resolve correctly<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Avoid pointing every host at the same public resolver with no cache: upstream rate limits and added latency both bite under sustained load. A local cache absorbs the repeat lookups that dominate real traffic.<\/p>\n\n\n\n
Does anything else depend on the resolver?<\/h2>\n\n\n\n