DNS Traffic Analysis

# CHAPTER 9

DNS Traffic Analysis #

1. Introduction #

The internet runs on IP addresses, but humans cannot memorize strings of numbers like 142.250.190.46. We memorize domain names like google.com. The Domain Name System (DNS) is the critical directory that translates human names into machine numbers. If DNS fails, the internet appears completely broken to the user, even if the physical network is functioning perfectly. Because almost every network interaction begins with a DNS query, mastering DNS analysis in Wireshark is a mandatory skill for any network engineer or security analyst. In this chapter, we will filter for DNS traffic, dissect the structure of Queries and Responses, and identify common DNS resolution failures.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Apply Wireshark display filters to isolate DNS traffic.

• Autopsy a Layer 7 DNS Query and identify the specific Record Type requested.

• Analyze a DNS Response and extract the resolved IP addresses.

• Correlate a DNS Query packet to its matching Response packet.

• Troubleshoot common DNS failures (e.g., NXDomain errors).

3. Beginner-friendly Explanations #

The Phonebook Request: Imagine you want to call a business called "TechStore."

1. 1. The Query: You pick up your phone, dial Directory Assistance (The DNS Server), and ask: *"What is the phone number for TechStore?"*

1. 2. The Response: The operator looks in the phonebook and replies: *"The number for TechStore is 555-0199."*

1. 3. The Connection: You hang up with the operator, and immediately dial 555-0199.

In Wireshark, you will physically see this exact process. Before your browser ever sends a TCP SYN packet to a website, you will see a rapid-fire UDP packet leaving your computer asking for the IP address, followed milliseconds later by the UDP response providing the IP.

4. Filtering for DNS Traffic #

DNS primarily utilizes UDP Port 53. To isolate this traffic in Wireshark, you simply type dns into the Display Filter bar and press Enter.

The Packet List pane will instantly clarify. The Info column will display highly readable summaries:

• Standard query 0x1a2b A google.com

• Standard query response 0x1a2b A google.com A 142.250.190.46

*Notice the Transaction ID (0x1a2b). Because UDP has no sequence numbers, DNS uses a random Transaction ID to mathematically link the specific Query to the specific Response.*

5. Dissecting the DNS Query #

Click on a packet labeled Standard query and look at the Middle Pane (Packet Details). Expand the Domain Name System (query) section. Expand the Queries folder. You will see exactly what your computer asked for:

• Name: google.com

• Type: A (Asking for an IPv4 address). If it was asking for an IPv6 address, the type would be AAAA.

• Class: IN (Internet).

6. Dissecting the DNS Response #

Click on the matching Standard query response packet. Expand the Domain Name System (response) section. Expand the Answers folder. Here, you will see the payload returned by the server:

• Name: google.com

• Type: A

• Address: 142.250.190.46

• Time to live: 300 (The server tells your computer to cache this answer in memory for 300 seconds so it doesn't have to ask again).

7. Troubleshooting DNS Failures #

If a user complains "The website is down," you filter for dns in Wireshark. You see the computer send the Query for badwebsite.com. You look at the Response packet. Instead of providing an IP address, the Flags section of the response says: Reply code: No such name (3) (Also known as an NXDomain error).

*The Diagnosis:* The network is fine. The DNS server is fine. But the user typed the website name wrong, or the website's domain registration expired. You have solved the ticket in 10 seconds.

8. Best Practices #

• Analyze the Name Resolution Time: By default, Wireshark can calculate how long a DNS query takes. If you expand a DNS Response packet, Wireshark injects a [Time:] field. If this time is consistently above 100ms (0.1 seconds), the user's internet will feel incredibly sluggish. This proves the ISP's DNS servers are congested, and you should switch the network to a faster public resolver like 1.1.1.1 or 8.8.8.8.

9. Common Mistakes #

• Ignoring CNAME Chains: A beginner looks at a DNS response and gets confused because it lists 5 different answers. Often, a website like www.company.com is an alias (CNAME) pointing to cdn.provider.net, which is an alias pointing to an actual A Record IP. Wireshark will show the entire cascading chain of aliases in a single response packet. Read the Answers folder carefully from top to bottom.

10. Mini Project: Capture a Live DNS Lookup #

1. 1. Open Wireshark and start a live capture.

1. 2. Open a command prompt / terminal.

1. 3. Type nslookup openai.com and press Enter.

1. 4. Stop the capture in Wireshark.

1. 5. Apply the display filter dns.

1. 6. Find the query for openai.com and examine the matching response. You will see the exact IP addresses that printed in your terminal window neatly decoded in the Wireshark GUI!

11. Practice Exercises #

1. 1. Explain how Wireshark (and the DNS protocol) correlates a specific UDP DNS Response packet to its originating UDP DNS Query packet, given that UDP is connectionless.

1. 2. What specific error code in a DNS Response packet indicates that the requested domain name does not exist on the internet?

12. MCQs with Answers #

13. Interview Questions #

• Q: Walk me through the exact process of identifying a DNS resolution failure using Wireshark. What specific filter would you use, and what packet details indicate an NXDomain error?

• Q: A user tries to visit a website. In Wireshark, you see the DNS Query packet leave the machine, but a DNS Response packet never returns. What network infrastructure issues could cause this?

• Q: Explain the significance of the "Time to live" (TTL) value found within the Answers section of a DNS Response packet.

14. FAQs #

Q: I applied the dns filter, but I don't see any DNS traffic when I browse the web. Why? A: Your operating system caches DNS answers. If you visited youtube.com five minutes ago, your computer already knows the IP address and doesn't need to ask the DNS server again. To force a new DNS query to appear in Wireshark, you must flush your local DNS cache (e.g., ipconfig /flushdns on Windows) before starting the capture.

15. Summary #

In Chapter 9, we isolated the foundational directory service of the internet. By utilizing simple display filters, we extracted DNS traffic from the chaotic stream of UDP background noise. We autopsied Layer 7 Queries and Responses, extracting requested domain names and their resulting IPv4 (A Record) resolutions. We leveraged Transaction IDs to link connectionless requests, and identified NXDomain response codes as rapid diagnostic indicators of bad URLs. Mastering DNS analysis in Wireshark allows engineers to instantly differentiate between physical routing failures and logical naming failures.

16. Next Chapter Recommendation #

The computer has successfully obtained the IP address. Now, it needs to actually download the website. Proceed to Chapter 10: HTTP and HTTPS Packet Analysis.