Guides / DNS latency

Finding DNS latency in a PCAPNG

Measure the time from a DNS query to its matching response, then group the slow results by resolver, client and queried name.

By Stuart Mathieson7 minute readWireshark + tsharkUpdated 25 September 2026

Start with response time, not packet gaps

Wireshark matches a DNS response to its request and exposes the elapsed time as dns.time on the response packet. To find responses slower than 250 milliseconds:

dns.flags.response == 1 && dns.time > 0.250

Change the threshold to suit the environment. A local recursive resolver may normally answer cached names in a few milliseconds; an uncached lookup that crosses several authoritative servers naturally takes longer.

Add columns for dns.qry.name, dns.time, source and destination. Sorting by DNS time immediately shows the worst samples. The field is listed in Wireshark's DNS display-filter reference.

Extract slow lookups with tshark

tshark -r capture.pcapng \
  -Y "dns.flags.response == 1 && dns.time > 0.250" \
  -T fields -E header=y -E separator=, -E quote=d \
  -e frame.time_epoch -e ip.src -e ip.dst \
  -e dns.id -e dns.qry.name -e dns.flags.rcode -e dns.time

This produces CSV-shaped output that is easy to sort or aggregate. For TCP-based DNS, the same DNS fields still apply; include tcp.stream if you need to separate long-lived resolver connections.

Interpret the result

A slow response does not automatically mean the resolver itself was slow. Check these cases:

Repeated query before the response: the first query or its response may have been lost. Filter on the same transaction ID and endpoints.
High latency only for uncached names: the delay may be upstream recursion rather than the client-to-resolver path.
High latency for every client using one resolver: investigate that resolver or its upstream connectivity.
Fast DNS response but slow application start: DNS is not the bottleneck. Continue with TCP connection and TLS handshake timing.
NXDOMAIN or SERVFAIL: inspect dns.flags.rcode. A quick error and a slow successful lookup are different problems.

Capture position matters.

If the trace starts after the query, or packet loss at the capture point hides one half of the exchange, Wireshark cannot calculate dns.time. Also check for mDNS on port 5353 and LLMNR on 5355; those are not ordinary client-to-recursive-resolver lookups.

Correlate DNS with the next connection

Once you find a slow name, note its answer address and response timestamp. Filter for the first SYN sent to that address:

ip.addr == 203.0.113.20 && tcp.flags.syn == 1

The interval between the DNS response and that SYN is client-side think time or scheduling, not DNS latency. The interval from SYN to SYN/ACK is connection setup time. Keeping those phases separate prevents DNS from being blamed for a slow TLS handshake or server response.

Manual method vs PCAPNG Analyzer

Manual method

Open Wireshark and filter DNS responses.
Add and sort the dns.time column.
Group slow results by resolver and name.
Inspect retries, response codes and the next TCP connection.

With PCAPNG Analyzer

Upload or auto-ingest the capture.
Use the DNS query and answer reports to identify active names and resolvers.
Open DNS packet details and compare matched timestamps.
Filter by endpoint and time to follow the subsequent connection.

Current product boundary

PCAPNG Analyzer decodes DNS queries, answers, response codes, TTLs and packet timestamps, but it does not yet calculate a dedicated per-query DNS latency field. Use Wireshark or the tshark command above when you need an exact response-time column.

Summarise DNS activity without sending captures away

PCAPNG Analyzer runs on your own server and turns packet data into filterable DNS, conversation and protocol reports.

Compare tiers Self-host it