DNS isn’t just a phonebook for the internet; it’s a hierarchical, distributed database that’s incredibly fragile and surprisingly complex, and most people only ever interact with it when it breaks.
Let’s watch a DNS query unfold. Imagine you’re trying to reach www.example.com.
- Your computer, acting as a DNS resolver, first checks its local cache. No luck.
- It sends a query to its configured DNS server (often provided by your ISP or set manually, like
8.8.8.8). The query is for theArecord ofwww.example.com. - Your DNS server receives this. It might have it in its cache. If not, it initiates its own recursive query process.
- It might ask a root DNS server (
.) "Where can I find.com?" The root server responds with the IP addresses of the.comTop-Level Domain (TLD) servers. - Your DNS server then asks one of the
.comTLD servers "Where can I findexample.com?" The TLD server responds with the IP addresses of the authoritative name servers forexample.com. - Finally, your DNS server asks one of the
example.comauthoritative name servers "What’s theArecord forwww.example.com?" - The authoritative server responds with the IP address for
www.example.com. - Your DNS server caches this response and sends it back to your computer.
- Your computer caches it and now knows how to connect to
www.example.com.
This entire dance happens in milliseconds, typically over UDP port 53. Wireshark captures all this traffic, letting you see each step.
To start, filter your Wireshark capture for DNS traffic: udp.port == 53. You’ll see a lot of queries and responses. A query is a request for information (e.g., "What’s the IP for www.example.com?"), and a response is the answer.
Let’s look at a typical query and response pair.
Query:
- Source: Your computer’s IP (e.g.,
192.168.1.100) - Destination: Your DNS server’s IP (e.g.,
8.8.8.8) - Protocol: UDP
- Info:
[A]www.example.com(This means it’s an 'A' record query forwww.example.com)
Response:
- Source: Your DNS server’s IP (e.g.,
8.8.8.8) - Destination: Your computer’s IP (e.g.,
192.168.1.100) - Protocol: UDP
- Info:
[A]www.example.comA 93.184.216.34(This is the 'A' record response, providing the IP address)
You can see the "Query ID" in Wireshark’s packet details pane. This is a 16-bit number that uniquely identifies a query. The response packet will have the same Query ID, allowing your computer to match responses to their original requests.
If you see a query but no corresponding response, or a response with a different Query ID, that’s a problem. You can right-click on a query packet, go to "Follow" -> "UDP Stream," and Wireshark will highlight all packets belonging to that UDP conversation, making it easy to spot missing responses.
The most surprising thing about DNS is how much reliance there is on UDP, which is connectionless and doesn’t guarantee delivery. DNS works because it’s designed for speed and has built-in retry mechanisms and caching, but this also means packet loss or delays can easily break the chain.
A common scenario is a slow or unresponsive DNS server. You’ll see your computer sending a query, but the response takes an unusually long time, or never arrives. In Wireshark, this looks like a query packet followed by a long gap before another query (perhaps to a different server) or nothing at all.
You can also examine different record types. While A records (IPv4 addresses) are most common, you’ll also see AAAA (IPv6 addresses), MX (Mail Exchangers), CNAME (Canonical Names or aliases), and NS (Name Servers). A query for MX records for example.com will return the mail servers responsible for that domain.
The one DNS behavior that trips up many people is how CNAME records work. When you request an A record for a hostname that is a CNAME, the DNS server will first return the CNAME record itself, pointing to another hostname. Then, your resolver (or the intermediate server) has to make a second query to find the A record for that new hostname. So, a seemingly simple lookup can involve multiple DNS round trips if CNAMEs are involved, and Wireshark will show you this layered resolution process.
When troubleshooting, always check the DNS server IP address configured on your client machine. A typo there means your queries go nowhere. You can find this in your OS network settings or by running ipconfig /all on Windows or cat /etc/resolv.conf on Linux/macOS.
If you suspect your ISP’s DNS server is the culprit, try switching to a public DNS resolver like Google’s (8.8.8.8 and 8.8.4.4) or Cloudflare’s (1.1.1.1 and 1.0.0.1) on your client machine temporarily and see if resolution improves.
The next common problem you’ll encounter after resolving basic query/response issues is understanding DNSSEC validation failures or misconfigured zone files on authoritative servers.