2026-06-02

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

How to diagnose DNS timeout, retransmission, no response, SERVFAIL, UDP loss, TCP fallback, resolver latency, and application delay with packet captures.

A browser's “site cannot be reached,” a five-second pause before connect, and an API timeout can all begin with DNS, but they do not describe the same resolver failure. Match each query ID and name to its response, retransmission, fallback server, CNAME chain, or SERVFAIL; no response is different evidence from a slow but explicit DNS error. The packet capture can measure resolver latency and show DNS queries visible at that interface, while cache decisions and failures beyond the recursive resolver need separate telemetry.

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:

Identify the client, resolver, and queried name.
Filter by DNS transaction ID and query name.
Measure query-to-response latency.
Check response code: NOERROR, NXDOMAIN, SERVFAIL, REFUSED, or no response.
Look for repeated queries and resolver failover.
Check whether UDP responses are large or fragmented.
Look for TCP fallback after truncation.
Compare system resolver behavior with application-specific DoH or DoT.
Preserve timestamps before trimming the capture.
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.

DNS outcome matrix

Match transaction ID, query name, type, client port, resolver, and time. IDs can be reused, so filtering by ID alone can merge unrelated exchanges. Record whether the application changes resolver, retries the same server, changes query type, appends a search suffix, or falls back from UDP to TCP.

Observed sequence	Bounded conclusion
Query, no response, identical retry	No response observed before client retry
Query, delayed NOERROR answer	Resolver path responded slowly
Query, SERVFAIL	Resolver explicitly failed processing
Query, NXDOMAIN	Name reported nonexistent for that query
UDP response with TC=1, then TCP	Standards-based truncation fallback
Large fragmented UDP response incomplete	Fragment/path issue is a lead
No port 53 traffic, HTTPS session to resolver	Application may use DoH

Does repeated DNS query prove the first query was lost?

No. The client may retry before a delayed response, the response may be absent only from the capture point, or the application may issue parallel queries. Two-sided captures or resolver logs are needed to locate loss.

How should CNAME chains be timed?

Preserve all queries and answers in the chain and distinguish client-to-recursive latency from recursive upstream work that is invisible at the client. A long gap before one answer is observable; which authoritative server consumed it requires resolver telemetry.

Why can AAAA and A create apparent delay?

Clients may query them in parallel or sequence and apply connection-racing policy. Record both query types and subsequent connection attempts. An AAAA failure does not necessarily delay IPv4 if the client races correctly.

How do search domains affect troubleshooting?

A short unqualified name may trigger several suffixed queries before the intended name. Preserve the ordered names and response codes. The delay may be resolver policy or application naming behavior rather than packet loss.

DNS incident report and focused capture

Include client, resolver, queried name/type, transaction IDs, query/retry/response times, response codes, answer TTL, UDP size/fragmentation, TCP fallback, resolver changes, and the first subsequent connection attempt. State capture point and whether DoH/DoT could bypass visible DNS.

Retain the first query through the final outcome and application connection boundary. Use capture scope help and the evidence preparation workflow while remembering that hostnames and answers are sensitive data.

Distinguish timeout, NXDOMAIN, and SERVFAIL

These outcomes lead to different owners. A timeout means no matching answer was observed before policy expired. NXDOMAIN is an explicit claim that the queried name does not exist in the relevant DNS context. SERVFAIL means the resolver could not complete processing, which can involve DNSSEC validation, upstream timeout, delegation, or internal failure.

Do not collapse them into “DNS down.” Record the exact response code, authority/answer sections where visible, resolver address, and whether another resolver returns a different result. Cached negative responses and split-horizon views can make tests differ by client or network.

Resolver comparison table

Test	Keep constant	What a difference suggests
Same client, two resolvers	name, type, time	resolver/path/policy difference
Two clients, same resolver	network and query	client cache or local interception
UDP then TCP	name and resolver	truncation or UDP path issue
Plain DNS versus DoH	application and name	different resolver/path stack
Warm versus cold cache	resolver and query	recursion/cache contribution

Can TTL explain repeated lookups?

Yes, but application caches, OS caches, negative caching, service discovery, and zero/low TTL policies all matter. Record the returned TTL and actual query interval; do not infer cache behavior solely from one answer.

What proves a DNS fix?

Repeat a controlled matrix with the same names, types, client, resolvers, and cache conditions. Require the expected response code within the target latency and verify the subsequent connection no longer waits on retry/fallback. Check resolver logs for the previously bounded interval when the root cause was upstream.

For escalation, provide a compact timeline rather than a screenshot: query at T0, retries, resolver changes, response/error at Tn, and first connection attempt. This lets resolver, network, and application owners test their exact boundary.

Preserve one successful control lookup from the same client and period. Compare query type, resolver, cache condition, response size, fallback, and connection timing. A healthy unrelated name proves only that some DNS traffic worked; a useful control is operationally comparable to the failed query.

When the answer changes during investigation, record TTL and authoritative state at each test time. Otherwise a legitimate DNS update can be mistaken for an intermittent packet problem.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: