DNS is actually a client-server protocol, not a broadcast one, meaning your machine explicitly asks a DNS server for an IP address and waits for an answer.
Let’s watch this in action. We’ll simulate a DNS lookup for www.example.com and capture the traffic.
# On your client machine
sudo tcpdump -i any -n 'udp port 53' -w dns_capture.pcap
# In another terminal on your client machine
dig www.example.com
Now, stop tcpdump with Ctrl+C. Open dns_capture.pcap in Wireshark and filter for dns. You’ll see your client sending a UDP packet to its configured DNS server (e.g., 192.168.1.1 or 8.8.8.8) on port 53. This packet contains the query for www.example.com. A moment later, you’ll see a UDP response packet from the DNS server back to your client, containing the IP address for www.example.com. The dig command, or your browser, then uses this IP to initiate a TCP connection.
The problem tcpdump helps us solve is understanding why name resolution fails or is slow. When you can’t reach a website, it’s often because the DNS lookup is the bottleneck or the point of failure. tcpdump lets us see the raw packets exchanged between your client and the DNS server, revealing issues that higher-level tools might obscure.
Internally, DNS resolution involves your operating system consulting a series of sources: first, its local cache. If not found, it queries its configured DNS resolver (often provided by your ISP or a public service like Google DNS at 8.8.8.8). This resolver might recursively query other DNS servers to find the authoritative answer. tcpdump captures the UDP packets on port 53 that represent these explicit requests and their answers.
The key levers you control are your client’s /etc/resolv.conf (or equivalent network settings) which dictates which DNS server to ask, and the firewall rules that might be blocking UDP port 53 traffic. tcpdump lets you inspect the actual packets flowing through these channels. You can see the query ID, the question asked (domain name and record type like A, AAAA, MX), and the flags set by the server (like recursion desired).
When you analyze a capture, you’ll notice a transaction ID in the DNS query and response. This ID is crucial for matching a specific request to its corresponding reply, especially if multiple queries are outstanding. The DNS server will echo this ID back in its response.
If you see a query going out but no response coming back, the problem could be network connectivity to the DNS server, a firewall blocking the UDP traffic, or the DNS server itself is down or overloaded. If you see a response, but it’s an error (like REFUSED or NXDOMAIN), then the DNS server is responding, but it doesn’t have the answer or isn’t configured to provide it.
The next thing you’ll want to investigate is the DNS server’s configuration itself, or deeper network path issues if the UDP packets aren’t even reaching their destination.