Troubleshoot DNS in Wireshark with a Small Local Lab

A browser failing to open a site is not enough evidence to diagnose DNS. The problem might be name resolution, connectivity, TLS or the application itself. A small capture from your own test environment can help you separate these stages, provided you understand what traffic the capture can actually see.

Define a narrow question

For this exercise, ask whether a conventional DNS query receives a response and what that response says. Capture on the interface carrying your own test traffic. Limit the capture duration and avoid collecting unrelated users’ traffic. A display filter changes what you see after collection; it does not limit what was captured.

# Wireshark display filters
dns
dns.flags.response == 0
dns.flags.response == 1
dns.qry.name == "example.com"
dns.flags.rcode == 3

Follow the question and answer together

Inspect the queried name, record type, transaction identifier, transport endpoints and response code. Pair a response with the corresponding query using more than the name alone, since multiple requests may overlap. A response can contain aliases and several records, so do not assume the first displayed address is the entire answer.

Distinguish a negative answer from no answer

NXDOMAIN indicates the responding DNS system says the queried name does not exist. A query with no observed response is a different situation: packet loss, capture placement, filtering or resolver behavior could explain it. The absence of a packet in your capture is not proof that no packet existed anywhere.

Account for caching and encrypted DNS

A second lookup may be answered from cache and produce no new network request. Browsers or operating systems may also use DNS over HTTPS or another encrypted transport. In those cases, a dns display filter may not reveal the lookup. Record the resolver configuration and the tool used to generate the test.

Write a small troubleshooting conclusion

Report the capture interface, time window, query name, response code and observed latency. State whether the evidence supports a resolution failure or whether you need to inspect the next stage. Avoid attributing a resolver response to the authoritative server unless the capture actually establishes that path.

Practice and check your understanding

Generate a lookup for example.com with a conventional DNS client and record its response. Repeat the lookup and explain any caching difference. Compare a successful answer with a negative answer in a disposable lab and keep the capture metadata.

Continue learning

Explore the related Code Hacker course syllabus for structured learning. Then read Normalize Time Zones Before Building a Forensic Timeline to connect this exercise to the next skill.

Reference

Wireshark DNS display filter reference provides the underlying API or technical guidance. Check the documentation for the version you use; examples here are small learning exercises rather than complete production implementations.