How to Find DNS Timeouts in Wireshark

To find possible DNS timeouts in a saved capture, apply this display filter:

dns && dns.flags.response == 0 && !dns.response_in

It selects queries for which Wireshark has no generated Response In link. These are investigation candidates—not confirmed timeouts. Retransmitted queries can also lack that link even when the original query eventually receives a response.

In Wireshark 4.4 and later, you can also use:

dns.response_missing

Wireshark documents that field as DNS response missing, available since 4.4.0. The 4.4.0 DNS dissector distinguishes missing responses from query retransmissions; neither label establishes that an application’s timer expired. Field names and version ranges are in the official DNS filter reference.

This workflow is for conventional unicast DNS. If the capture also contains other name-resolution traffic, restrict the candidate filters to port 53 by appending && (udp.port == 53 || tcp.port == 53).

1. Capture the lookup from the right place

Inspect only systems and traffic you own or are authorized to examine. Start capturing before reproducing the failure, and keep the capture running through the application’s error and any later reply.

For a client-side timeout, capture where the client’s resolver traffic is visible. Check whether the application uses a local DNS service, a VPN interface, or a different resolver from the operating system. Traffic between a machine and itself is not visible on its physical adapter; use a supported loopback capture interface, as explained in Wireshark’s loopback guide. For wireless interface selection, see how to capture packets from a wireless client.

Prefer a short capture with enough surrounding traffic to investigate the failure. A UDP-only port-53 capture excludes TCP fallback; a DNS-only capture excludes useful transport and ICMP evidence. Apply display filters afterward: they hide packets without removing them from the file, as the Wireshark user guide explains.

For conventional DNS on port 53, begin with:

dns && (udp.port == 53 || tcp.port == 53)

If you see no queries, do not conclude that DNS worked—or failed. A cached answer may require no network exchange. DNS over HTTPS and DNS over TLS encrypt the DNS messages, so these filters cannot inspect an undecrypted exchange. See the DoH specification, the DoT specification, and what HTTPS leaves visible. For encrypted DNS, correlate endpoint resolver logs with connection timing instead.

2. Separate unanswered queries, retries, and slow replies

Use these filters on the completed capture:

Investigation	Display filter	What it tells you
Queries without a response link	dns && dns.flags.response == 0 && !dns.response_in	Wireshark has no response link on that query packet; inspect retries too.
Missing-response annotation, Wireshark 4.4+	dns.response_missing	Wireshark has marked a query as lacking a matched response.
Query retransmissions	dns.retransmit_request	Wireshark recognized a repeated query.
Replies taking more than one second	dns.flags.response == 1 && dns.time > 1	A matched response arrived after the chosen threshold.
Common DNS error replies	dns.flags.response == 1 && dns.flags.rcode != 0	A reply arrived with a nonzero header response code.

These fields are defined in Wireshark’s DNS reference. One second is a triage threshold, not a universal DNS timeout. A timeout is the resolver or application’s decision to stop waiting; the packet capture does not directly expose that timer.

To exclude Wireshark-recognized retransmissions from the first filter, use:

dns && dns.flags.response == 0 && !dns.response_in && !dns.retransmission

Still review retransmissions separately. A retry that changes the transaction ID, client port, or resolver may need manual grouping rather than relying on Wireshark’s retransmission annotation.

3. Rebuild the lookup timeline

Select a candidate and expand Domain Name System in Packet Details. Record:

• Query name, type, and class.
• Client and resolver addresses, transport, and ports.
• Transaction ID (dns.id).
• Packet timestamp and any Response In, Request In, or retransmission link.

Wireshark’s bracketed response links and timing fields are generated analysis, not fields sent on the wire. Double-click a packet link to jump to its counterpart. The Packet Details documentation describes both behaviors.

Narrow to the queried name, using a redacted example here:

dns.qry.name == "service.example"

Then distinguish query types and clients. An A query and an AAAA query for the same name are different questions, not automatically retries. Match the question and transaction ID within the relevant address-and-port exchange; a transaction ID alone is insufficient. The DNS query-matching rules require more than an ID match. A Wireshark response link is an analysis aid, not proof that the resolver accepted the reply.

Set View → Time Display Format → Seconds Since First Captured Packet, then compare timestamps. To read times relative to the first query, select it and use Set Time Reference (toggle) from the Packet List context menu, following the Wireshark time-reference guide.

For example, this illustrative timeline—not a measured capture suggests a wait followed by resolver failover:

Relative time	Event
0.000 s	Client queries resolver A.
1.000 s	Client repeats the same question to resolver A; no reply is visible.
3.000 s	Client sends the question to resolver B.
3.040 s	Resolver B replies.

The exchange with B took 40 ms, but the visible sequence lasted 3.040 seconds from the first query. dns.time measures the interval for Wireshark’s matched request-response pair, not the entire application’s resolution attempt. Check Request In to see which query the timing uses, especially around retries. The dissector’s timing calculation subtracts the tracked request timestamp from the reply timestamp.

4. Decide what the evidence supports

No matched reply: Check capture start and end times, interface coverage, capture filters, packet drops, and incomplete packet data. A query near the end of the file may simply have its reply outside the recording. Report “no matching response observed” until logs or a complete reproduction establish a timeout.

Repeated questions followed by an application error: Correlate the error timestamp and configured timeout with the packet timeline. This supports a client-side timeout, but a client capture alone cannot locate the loss. Compare authorized client- and resolver-side captures to determine whether the resolver received the query and sent a reply.

A slow matched reply: This is observed DNS response delay, not automatically a timeout. At the client, that interval includes network travel and resolver work; it does not isolate server processing time.

NXDOMAIN, SERVFAIL, or REFUSED: These are replies, not missing replies. Their response codes describe a negative result or failure, as defined in RFC 1035. A resolver’s upstream timeout could contribute to a failure response, but the client-side code alone does not prove that cause.

A truncated UDP reply: Find it with udp && dns.flags.response == 1 && dns.flags.truncated == 1. Then replace the DNS filter with tcp.port == 53 and narrow to the resolver’s address so you can see connection setup as well as DNS messages. Truncation indicates that the client should retry over TCP; blocked or failed TCP can cause resolution failure even though UDP received a reply. RFC 7766 explains this fallback and its failure implications.

Export candidates with TShark

For a large saved capture, list query packets without response links:

tshark -2 -r capture.pcapng -Y 'dns && dns.flags.response == 0 && !dns.response_in' -T fields -e frame.number -e frame.time_relative -e dns.id -e dns.qry.name -e dns.qry.type -e dns.retransmission -e dns.retransmit_request_in

The -2 option matters: two-pass analysis lets TShark populate fields requiring knowledge of later packets, including response-frame links. -Y supplies the display filter and -T fields selects field output; these options are documented in the TShark manual. In Windows Command Prompt, use double quotes around the filter instead of single quotes.

Treat the output as a candidate list, not a timeout count. Before sharing findings, redact names, addresses, identifiers, and sensitive payloads; share a minimal timeline rather than third-party packet data.