DNS Analysis in Wireshark: 3 Investigation Patterns

DNS problems often look simple in a packet list: a query, a response, and a return code. The difficult part is deciding whether the resolver, upstream service, network path, client behavior, or capture position explains the user's symptom.

Start with dns, isolate one client and question name, and match each query to its response using transaction ID, endpoints, transport, and timing. Then use one of these investigation patterns.

Pattern 1: queries appear unanswered

An unanswered query can mean packet loss, a resolver that did not respond, a retry sent to another server, an asymmetric capture, or a capture that ended too soon. It does not automatically prove a DNS server outage.

Useful pivots include:

dns.flags.response == 0
dns.flags.response == 1
dns.id == 0x1234
dns.retransmission
dns.response_in
dns.response_to
dns.time

Workflow:

1. Identify the original client, resolver, question name, and query type.
2. Search for the same transaction in both directions.
3. Check whether the client retries the same resolver, changes resolver, or switches transport.
4. Compare another query that succeeds from the same client.
5. State whether the response is absent from the network path or merely absent from this observation point.

Pattern 2: DNS is blamed for application delay

Measure the query-to-response interval with dns.time, but align it with the application timeline. A 200 ms DNS response is irrelevant if the application stalls five seconds later during TCP or TLS setup. Conversely, repeated timeouts before a successful fallback resolver can dominate page load time.

Compare:

• first query versus retries
• A/AAAA/HTTPS/SVCB or other related query types
• primary resolver versus fallback resolver
• affected hostname versus a successful baseline
• UDP queries versus TCP fallback when responses are truncated

dns.flags.rcode != 0 finds error responses, not slow successful responses. NXDOMAIN may be an expected application lookup, while SERVFAIL or REFUSED requires resolver and policy context.

Pattern 3: suspicious DNS behavior

Long or encoded-looking labels, many unique subdomains, TXT queries, unusual volume, and low-value responses can support a DNS-tunneling hypothesis. None is sufficient alone: CDNs, telemetry, security products, and service discovery can generate similar patterns.

Start with bounded questions:

dns.qry.type == 16
dns.flags.response == 0
dns.qry.name.len > 80

Then establish:

• which endpoint generates the queries
• uniqueness and length distribution of labels
• cadence and total transferred data
• response size and return codes
• whether the domain and endpoint are expected
• whether the behavior persists across a meaningful time window

The malicious-traffic analysis workflow demonstrates how to preserve exact filters and frames while keeping the conclusion scoped.

Evidence that strengthens a DNS conclusion

A better conclusion

Avoid “Wireshark found DNS poisoning” based on mismatched-looking names. CNAME chains, aliases, cached answers, and different query types can all look surprising.

Prefer language such as:

Client 10.0.8.24 sends six A queries for the same name to resolver A without a visible response, then resolver B answers in 18 ms. The retry sequence accounts for 5.1 seconds of the application start delay. The capture supports failure on the resolver-A path, but does not distinguish resolver silence from a missing reverse-path capture.

That statement is reproducible and makes the next check obvious.

Use the PacketSafari analyzer when you need to correlate DNS behavior with the TCP, TLS, and application events that follow while retaining exact packet evidence and explicit uncertainty.