DNS Resolution with `dig`

1. The DNS Hierarchy: A Chain of Command

Before we start digging, let's understand the journey a DNS query takes. It’s not a simple one-step lookup; it’s a hierarchical process involving several types of servers. The phone book analogy is a good start, but it's more like a series of receptionists who keep redirecting your call until you reach the right person.

The key players in this process are:

• Stub Resolver: The DNS client on your own computer. It's "stubborn" and simple; its only job is to ask the next server in line, the Recursive Resolver.
• Recursive Resolver (or Recursor): This is the workhorse. It's usually your Internet Service Provider's (ISP) DNS server or a public one like Google's (8.8.8.8) or Cloudflare's (1.1.1.1). When it receives a query, its job is to do whatever it takes to find the final answer. It does this by performing iterative queries.
• Root Name Servers: The 13 groups of servers at the very top of the hierarchy. They don't know the IP for google.com, but they know who to ask for anything ending in .com.
• Top-Level Domain (TLD) Name Servers: These servers manage specific TLDs like .com, .org, or .net. They don't know the IP for google.com either, but they know who is in charge of the google.com domain.
• Authoritative Name Servers: This is the final destination. This server holds the actual DNS records for a specific domain (e.g., google.com) and provides the definitive, or authoritative, answer.

The following video provides an excellent and engaging overview of this entire process.

2. Your DNS "Katana": The dig Command

To investigate this process, we need a professional tool. While commands like ping or nslookup can resolve a domain name, dig (Domain Information Groper) is the preferred tool for network and system administrators. It gives you far more detail and control, making it your "katana" for slicing through DNS problems.

First, let's make sure you have it installed. dig is part of a package of DNS utilities.

Now that dig is installed, let's learn how to use it. A basic dig command can seem overwhelming at first due to its verbose output.

As a quick reference, the Linuxize article also has an excellent, detailed breakdown of the output sections. It’s a great companion to the video.

3. Tracing the Full Path with dig +trace

Now for the main event. How can we see the entire chain of command from the Root servers all the way down to the Authoritative server? dig has a powerful option for this: +trace.

When you use +trace, dig stops using your system's default recursive resolver. Instead, it acts like a recursive resolver itself, performing the step-by-step iterative queries.

Let's run this command yourself in your terminal:
dig google.com +trace

You will see output similar to the image above. It might look complex, but it's just a sequence of simple questions and referrals.

1. Query to Root Servers: dig starts by asking one of the root servers (e.g., a.root-servers.net.) for google.com.
2. Referral to TLD Servers: The root server responds, "I don't know, but here is a list of the .com TLD servers. Go ask them."
3. Query to TLD Servers: dig picks one of the .com TLD servers (e.g., a.gtld-servers.net.) and asks it for google.com.
4. Referral to Authoritative Servers: The TLD server responds, "I don't know either, but google.com told me that ns1.google.com. is their authoritative name server. Go ask it."
5. Query to Authoritative Server: dig then asks ns1.google.com. for the address of google.com.
6. The Authoritative Answer: Finally, ns1.google.com provides the answer: the A record containing the IP address. Notice the aa flag in the header of this final response, which stands for "Authoritative Answer".

To really solidify your understanding of how +trace works under the hood, the following reading is invaluable. It manually recreates the +trace process using a series of individual dig commands.

Your Turn: Practice Tracing

Theory and examples are great, but practical application is your "katana". Time to wield it.

1. Open your terminal.
2. Pick a few websites you use often (e.g., github.com, reddit.com, or a news site from your country).
3. For each one, run dig <domain> +trace.
4. As you look at the output, identify the three main stages:
   • The referral from the root server to the TLD server.
   • The referral from the TLD server to the authoritative name server.
   • The final authoritative answer (aa flag) from the domain's own name server.

This exercise will prepare you to explain the DNS resolution process with confidence—a common task in technical interviews.

Conclusion

You've now peered behind the curtain of the internet's address book. You've gone from simply knowing that DNS exists to being able to trace its every step and diagnose its behavior with a powerful command-line tool.

Key Takeaways:

• DNS resolution is a hierarchical process involving Root, TLD, and Authoritative name servers.
• Your computer's stub resolver makes a request to a recursive resolver, which performs iterative queries to find the answer.
• The dig command is the professional standard for querying DNS servers and troubleshooting issues.
• dig +trace simulates the entire iterative lookup process, showing you the full delegation path from the root servers down to the final answer. This is your primary tool for diagnosing DNS resolution failures.

In our next lesson, we'll shift our focus slightly. We now know how a name gets resolved to an IP address. But how does your computer get an IP address in the first place when it joins a network? We will investigate this by observing a DHCP lease assignment and identifying the DORA (Discover, Offer, Request, Acknowledge) process steps in a packet capture.