Triage DNS and TCP Problems with Wireshark

Packet captures can show where a connection attempt stops: before DNS returns an answer, during the TCP handshake, or after the application begins exchanging data. This guide uses Wireshark display filters to investigate one controlled test flow.

Capture only traffic you are authorized to inspect. Packet captures can contain personal data, credentials sent by insecure protocols, internal addresses, and other sensitive information; store and share them accordingly.

---

Step 1: Choose the Right Capture Point and Interface

01

Capture Near the Affected Client or Service

Capture Setup

Start with the smallest capture that can answer the question. Capture on the affected client or server, select its active interface, and reproduce one connection attempt with a recorded timestamp and destination. On a switched network, a capture from an unrelated workstation may not see another host’s unicast traffic.

Capture host: affected test client
Interface: active Ethernet or Wi-Fi adapter
Test: resolve app.example.test, then open TCP/443

❯ View Expected Console Output

Start the capture, perform one test, and stop the capture promptly.

---

Step 2: Inspect the DNS Query and Response

02

Filter DNS Packets and Match Query IDs

Name Resolution

Enter dns in the display filter bar. Find the query for the target name and compare it with the response that has the same transaction ID. Check the response code, answer section, and server address. A display filter hides packets from view; it does not remove them from the capture file.

dns
dns.qry.name == "app.example.test"
dns.flags.rcode != 0

❯ View Expected Console Output

Standard query A app.example.test
Standard query response A 10.20.40.15

Figure 1: Match the DNS response to the query by transaction ID.

---

Step 3: Read the TCP Handshake

03

Follow SYN, SYN-ACK, and ACK Packets

Transport

Filter for the destination and TCP port, then follow the stream or inspect sequence numbers. A client SYN without a reply can indicate filtering, routing, or a down host; repeated SYNs with no SYN-ACK are not proof of a firewall by themselves. A reset or successful three-way handshake narrows the next check to the listener or application.

ip.addr == 10.20.40.15 && tcp.port == 443
tcp.flags.syn == 1 && tcp.flags.ack == 0
tcp.flags.reset == 1

❯ View Expected Console Output

Client -> Server  SYN
Server -> Client  SYN, ACK
Client -> Server  ACK

Figure 2: Inspect the TCP three-way handshake for the test flow.

---

Step 4: Look for Retransmissions and Timing Gaps

04

Use TCP Analysis Flags as Leads

Packet Timing

Check Wireshark’s TCP analysis annotations for retransmissions, duplicate acknowledgments, and out-of-order packets. These are clues to investigate packet loss, congestion, asymmetric paths, or capture limitations; a single annotation does not identify the root cause. Compare timestamps and sequence numbers around the affected flow.

tcp.analysis.retransmission
tcp.analysis.duplicate_ack
tcp.stream eq 0

❯ View Expected Console Output

Use Follow > TCP Stream to isolate one conversation, then inspect its packet timing.

Figure 3: TCP analysis flags highlight retransmissions and duplicate acknowledgments.

---

Step 5: Save a Minimal, Protected Evidence Set

05

Record the Filter and Capture Context

Documentation

Save the original capture only when permitted by policy. Record the capture point, interface, time zone, reproduction steps, display filter, and relevant endpoint addresses. If sharing a capture, remove or protect unrelated traffic and sensitive payloads under your evidence-handling policy.

Case note: issue time, client, destination, interface, filter, observations
Capture file: restricted location; access logged if required

❯ View Expected Console Output

The resulting note lets another analyst reproduce the same packet review.

See the Wireshark User’s Guide for capture/display filters and packet analysis features.