DNS Retransmission and Timeout PCAP Analysis: Finding Slow Resolvers, Lost Queries, and Broken Responses

DNS failures often masquerade as application failures. A browser says a site cannot be reached. An API client shows a timeout. A service takes five seconds before opening a connection. Users search for "DNS timeout pcap", "DNS retransmission Wireshark", "DNS query no response", "slow DNS resolver packet capture", and "SERVFAIL vs timeout" because the visible error rarely explains whether name resolution failed, the resolver was slow, or the network lost packets.

A packet capture can answer this precisely if you keep the DNS query, response, timing, retransmission, and fallback behavior intact.

PCAP Surgery is useful because DNS evidence is often buried inside a large trace. You may need to isolate one client, one resolver, one domain, and one time window while preserving timestamps and request IDs.

What a healthy DNS exchange looks like

A basic UDP DNS exchange is short:

Client -> Resolver: Query A example.com
Resolver -> Client: Response A example.com 93.184.216.34

The important fields are:

• Query name
• Query type
• Transaction ID
• Source and destination port
• Resolver address
• Response code
• Answer records
• Timing between query and response

If the response comes back quickly with NOERROR, DNS probably is not the delay source. If there is no response, delayed response, repeated query, or error response, DNS becomes part of the diagnosis.

DNS timeout vs DNS error

A timeout means the client did not receive a usable response before its resolver logic gave up or retried. A DNS error means the resolver returned a response with an error code such as:

• NXDOMAIN: domain does not exist.
• SERVFAIL: resolver failed to complete resolution.
• REFUSED: resolver refused the query.
• FORMERR: format error.

These are different failures. A timeout points to packet loss, resolver unavailability, firewall, routing, or delayed response. SERVFAIL points to resolver recursion, DNSSEC, upstream server, or authoritative lookup problems. NXDOMAIN may be a real name problem or a search-domain/configuration issue.

Retransmission and retry behavior

DNS over UDP does not have transport-level retransmission like TCP. If a client does not receive a response, it sends another query. The retry may go to the same resolver or a different resolver.

A trace may show:

0.000 Client -> 8.8.8.8 Query example.com
1.000 Client -> 8.8.8.8 Query example.com
2.000 Client -> 1.1.1.1 Query example.com
2.030 1.1.1.1 -> Client Response example.com

This suggests the first resolver did not answer in time, while the second did. The application delay includes the time spent waiting for the first resolver.

Lost query vs lost response

With one capture point, you may not know whether the query or response was lost. Capture location matters.

If you capture on the client and see the query leave but no response arrive, the response may have been lost, blocked, delayed, or never generated. If you capture on the resolver and never see the query, the query was lost before reaching the resolver or blocked on the path. If the resolver sees and answers the query but the client never sees the response, the loss is on the return path.

Two captures are stronger:

• Client-side capture
• Resolver-side capture

Together they can prove whether the packet disappeared before the resolver, after the resolver, or inside the client host.

UDP fragmentation and large DNS responses

DNS responses can become large because of DNSSEC, many records, TXT records, or EDNS0 buffer sizes. Large UDP responses may fragment. Fragmentation can fail across firewalls or NAT devices.

Symptoms include:

• Small DNS queries work.
• Large responses time out.
• DNSSEC domains fail more often.
• TCP fallback succeeds.
• Responses with truncation bit lead to retry over TCP.

If a resolver sets the truncated bit, the client may retry over TCP. That is normal. If TCP fallback is blocked, the user may see DNS timeouts or intermittent failures.

DNS over TCP, DoT, and DoH

Classic DNS uses UDP and TCP port 53. Modern environments may use DNS over TLS or DNS over HTTPS. A normal packet capture may not expose domain names for encrypted DNS, but it can still show timing, connections, retries, and server reachability.

When analyzing application delay, first determine which resolver path is used. A browser may use DoH while system tools use the operating system resolver. That can explain why nslookup works but the browser fails, or why one application is slow while another is not.

Search domains and repeated queries

Enterprise and VPN environments often append search domains. A simple lookup for service may produce queries like:

service.corp.example.com
service.office.example.com
service

If several of those time out before the final name works, the user experiences delay. The final response may be correct, but the lookup path was slow.

A good DNS trace preserves the full query sequence, not only the final successful answer.

Checklist for DNS PCAP analysis

Use this process:

1. Identify the client, resolver, and queried name.
2. Filter by DNS transaction ID and query name.
3. Measure query-to-response latency.
4. Check response code: NOERROR, NXDOMAIN, SERVFAIL, REFUSED, or no response.
5. Look for repeated queries and resolver failover.
6. Check whether UDP responses are large or fragmented.
7. Look for TCP fallback after truncation.
8. Compare system resolver behavior with application-specific DoH or DoT.
9. Preserve timestamps before trimming the capture.
10. Correlate DNS delay with application connection timing.

Final diagnosis

DNS timeout analysis is not just "the domain failed." The packet evidence can show whether the resolver was slow, the query was lost, the response was lost, the response was an error, fallback happened, search domains added delay, or encrypted DNS used a different path.

PCAP Surgery supports the investigation by letting you isolate the DNS evidence while preserving the timing and packet sequence that explain the real user-visible delay.