# DNS and the dig Command: Understanding Internet's Address Resolution When we type `microsoft.com` into our browser, something magical happens instantly. Our computer transforms a human-readable domain name into an IP address, connects to the right server, and retrieves the content we need. But how does this magic work? We use the Domain Name System (DNS) every single day, often without thinking about it. Just like we don't memorize phone numbers anymore but instead look up names in our contacts, our computers don't need to remember that Microsoft web server lives at `13.107.213.68`. Instead, DNS resolves the name to the address automatically. **The problem DNS solves:** IP addresses are hard to remember. We can't ask users to visit `13.107.213.68` instead of `microsoft.com`. DNS bridges this gap by maintaining a distributed, hierarchical database that maps domain names to IP addresses. --- ## Part 1: What is DNS and Why Name Resolution Exists ### The Need for DNS When we connect to a website, our browser needs the IP address of the server hosting that site. Without DNS, we'd need to: 1. Manually look up the IP address somewhere 2. Type it into our browser 3. Remember hundreds of IP addresses for the sites we visit regularly This is impractical. DNS automates this process at a global scale. ### How DNS Works at a High Level DNS is a hierarchical, distributed system. When we request `microsoft.com`, our computer doesn't ask one central database. Instead, it queries a series of name servers in this order: 1. **Recursive Resolver** (usually our ISP or a public resolver like 8.8.8.8) 2. **Root Name Server** (knows where to find TLD servers) 3. **TLD Name Server** (knows where to find authoritative servers for the domain) 4. **Authoritative Name Server** (has the actual IP address) Each layer in this hierarchy knows just enough to point us to the next layer. This distributed approach makes DNS resilient, fast, and scalable. ### The DNS Hierarchy ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769714712360/7088f95e-27fc-49bb-9d92-6cfd5bd9297a.png align="center") --- ## Part 2: The dig Command - Your DNS Detective Tool ### What is dig? `dig` stands for **Domain Information Groper**. It's a command-line utility that allows us to query DNS servers directly and see exactly what's happening during name resolution. Instead of relying on our browser or operating system to silently resolve names, `dig` shows us the complete conversation with DNS servers. ### Why We Use dig As engineers we building distributed systems, we need visibility into DNS resolution. `dig` is our diagnostic tool for: * **Troubleshooting DNS issues** - Why isn't my domain resolving? * **Understanding the hierarchy** - How are name servers configured? * **Inspecting record types** - What's the MX record for this domain? * **Testing DNS propagation** - Has my new DNS record gone live? * **Learning how DNS works** - This is why we're here! ### Installing dig On **Linux/Mac**: Usually pre-installed. If not we can install by : ```bash # Ubuntu/Debian sudo apt-get install dnsutils # Mac brew install bind-tools ``` On **Windows**: Have to use Windows Subsystem for Linux (WSL), or have to install BIND utilities. --- ## Part 3: Understanding the DNS Resolution Layers Now let's walk through each layer of DNS resolution using actual `dig` commands. We'll build understanding step by step. ### Layer 1: Root Name Servers - The Starting Point Let's ask a root name server about the domain `.` (which represents the root of the DNS hierarchy): ```bash dig . NS ``` **What this command does:** * We query for **NS records** (Name Server records) for the root domain * NS records tell us which servers are authoritative for a domain **Expected output :** ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769831128079/e4bdccb5-12e7-4e26-85be-1dd7a29b1f79.png align="center") **What this tells us:** * There are 13 root name servers (a through m) * They are named `a.root-servers.net`, `b.root-servers.net`, etc. * Each has a TTL (Time To Live) of 518400 seconds (6 days) * These servers form the top layer of the DNS hierarchy **Why root servers matter:** Root servers are the starting point for all DNS queries. When we request `microsoft.com`, a recursive resolver first asks a root server: "I don't know where microsoft.com is. Do we have a TLD server for .com domains?" The root server responds: "I don't handle microsoft.com, but here are the TLD servers for .com—ask them." ### Layer 2: TLD Name Servers - The Directory Now let's query the TLD (Top-Level Domain) servers for `.com`: ```bash dig com NS ``` **Expected output:** ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769831278139/005986ac-302a-486d-be42-98121db7985d.png align="center") **What this tells us:** * There are multiple TLD servers for `.com` * They're called gTLD (Generic Top-Level Domain) servers * The TTL is 172800 seconds (2 days) **Why TLD servers matter:** TLD servers know which companies own which domains. When a recursive resolver asks "Where is microsoft.com?", the TLD server for `.com` responds: "Microsoft owns microsoft.com. Ask their authoritative name server." This is like asking "Where does someone named Kris live?" at a local directory. The directory doesn't know every Kris's address, but it knows which neighborhoods have Kris, and it points we to the right neighborhood. ### Layer 3: Authoritative Name Servers - The Truth Finally, let's query the authoritative name servers for `microsoft.com`: ```bash dig microsoft.com NS ``` **Expected output:** ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769835920397/c8a657a5-461d-439b-af64-e9789ef836f8.png align="center") **What this tells us:** * Microsoft operates four authoritative name servers for their domain * These servers are `ns1-39.azure-dns.com` through `ns439.azure-dns.`info * They're the source of truth for microsoft.com's DNS records **Why authoritative servers matter:** These servers actually have the IP addresses and other records for microsoft.com . When we ask an authoritative server "What's the IP address of microsoft.com?", it gives us the definitive answer. This is the final layer in our DNS hierarchy. ### Understanding NS Records **NS records are crucial.** They answer the question: "Who are the name servers for this domain?" Think of NS records like this: * **Root domain NS records** → "Here are the TLD servers" * **TLD domain NS records** → "Here are the authoritative servers for that domain" * **Domain NS records** → "Here are our authoritative servers" Each level delegates responsibility to the next level. This delegation is what makes DNS scalable. The root doesn't need to know about every domain in the world—only about top-level domains. --- ## Part 4: The Complete DNS Resolution Flow Now let's put it all together. When we visit `microsoft.com`, here's what happens: ```bash dig microsoft.com ``` This single command triggers a complex chain of events. Let's understand the output: **Expected output :** ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769839789946/976c0396-f296-4cb2-b0c8-c165f42a4c39.png align="center") ### Breaking Down the Output **QUESTION SECTION:** * We're asking for the **A record** (IPv4 address) of `microsoft.com` **ANSWER SECTION:** * `microsoft.com` resolves to IP address `13.107.213.68` * TTL is 300 seconds (5 minutes)—the browser will cache this for 5 minutes **AUTHORITY SECTION:** * Shows the authoritative name servers for microsoft.com * This confirms that the answer came from an authoritative source The Behind-the-Scenes Recursive Resolution Here's the step-by-step process that actually happens: 1. **Browser queries the local resolver** (often our ISP's resolver) * "What's the IP for microsoft.com?" 2. **Local resolver queries a root server** * "I don't know microsoft.com. Do we have a server for .com domains?" 3. **Root server responds** * "Ask the .com TLD servers" (returns list of TLD servers) 4. **Local resolver queries a TLD server** * "Do we have a server for microsoft.com?" 5. **TLD server responds** * "Ask Microsoft’s authoritative servers" (returns list of ns1-39.azure-dns.com, etc.) 6. **Local resolver queries microsoft.com's authoritative server** * "What's the IP address for microsoft.com?" 7. **Authoritative server responds** * "It's 13.107.213.68" 8. **Local resolver caches the answer and returns it to the browser** * Browser now has the IP and can establish a connection ### Visual Flow Diagram ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769837238088/75a1b212-e89c-459e-9620-abe576dd3353.png align="center") --- ## Part 5: Recursive Resolvers - The Silent Helpers We've focused on authoritative servers, but there's an unsung hero: the **recursive resolver**. When we use `dig`, by default we're querying a recursive resolver (usually our ISP's or a public one like google’s 8.8.8.8). The recursive resolver does all the heavy lifting: * It doesn't know the answer to "What's microsoft.com?" * So it recursively queries the root server * The root doesn't know, so it asks the TLD server * The TLD doesn't know, so it asks the authoritative server * The authoritative server knows and returns the answer * The resolver passes this back to us and caches it **Key insight:** Our browser doesn't contact all these servers directly. The resolver does the work on our behalf. This is why it's called "recursive"—it recursively follows the chain until it gets an answer. If we want to query a specific server (not a recursive resolver), we use `dig @server.name`: ```bash # Query a root server directly dig @a.root-servers.net microsoft.com # Query a TLD server directly dig @a.gtld-servers.net microsoft.com ``` Direct queries often return different results because authoritative and root servers may not have the full answer—they know enough to point us to the next server. --- ## Part 6: Connecting to Real-World Browser Requests Now let's connect this technical knowledge back to what happens when we visit a website. ### The Full Journey from Browser to Website 1. **We type** `microsoft.com` in the browser 2. **Browser needs the IP address:** * Checks its cache (is microsoft.com already resolved?) * If not, queries the operating system 3. **OS checks its DNS cache:** * If found, returns it * If not, queries the configured resolver 4. **Resolver performs the recursive resolution** (as we described above) * Returns: 13.107.216.68 5. **Browser now has the IP address** * Establishes a TCP connection to 13.107.213.68 (or :443 for HTTPS) 6. **Browser sends HTTP request** * "GET / HTTP/1.1\\nHost: microsoft.com\\n..." 7. **Server at** 13.107.213.68 responds * Sends back the HTML, CSS, JavaScript, etc. 8. **Browser renders the page** The DNS lookup happens in milliseconds, making it invisible to users. But without it, the entire web would be inaccessible. ### Practical Implications for Engineers **Why we care about DNS:** 1. **Domain migrations** - When we move our site to a new server, we update DNS records. DNS propagation delays can cause downtime. 2. **Load balancing** - We can point one domain to multiple IPs. DNS distributes traffic by returning different IPs in rotation. 3. **Failover** - If one server goes down, we update DNS to point to a backup. 4. **Regional routing** - We can return different IPs based on the user's location, routing them to the nearest server. 5. **Email routing** - MX records tell mail servers where to deliver emails. 6. **Security** - SPF and DKIM records help prevent email spoofing. --- ## Part 7: Useful dig Commands for Engineers Now that we understand the hierarchy, let's look at practical commands we'll use regularly: ### Basic A Record Lookup ```bash dig microsoft.com ``` Returns the IPv4 address of google.com. ### IPv6 Address Lookup (AAAA Record) ```bash dig microsoft.com AAAA ``` Returns the IPv6 address if available. ### Mail Server Lookup (MX Record) ```bash dig microsoft.com MX ``` Shows which servers handle email for google.com. ### Text Record Lookup (TXT Record) ```bash dig microsoft.com TXT ``` TXT records are used for SPF (spam prevention), DKIM (email authentication), and DMARC (domain policy). ### Name Server Lookup (NS Record) ```bash dig microsoft.com NS ``` Shows the authoritative name servers. ### CNAME Record Lookup ```bash dig www.example.com ``` If www.example.com is a CNAME (Canonical Name), it returns what it's aliased to. ### Query Specific Name Server ```bash dig @ns1-39.azure.dns.com google.com ``` Query a specific server instead of the default resolver. ### Short Output Format ```bash dig +short microsoft.com ``` Returns just the IP, no extra information. ```bash dig +trace microsoft.com ``` Shows the entire resolution path from root to authoritative server --- ## Part 8: Key Concepts Summary ### The DNS Hierarchy ```plaintext ROOT SERVERS ↓ (delegates to) TLD SERVERS (.com, .org, .net, etc.) ↓ (delegates to) AUTHORITATIVE SERVERS (google.com, example.com, etc.) ``` ### Types of DNS Servers | Server Type | Role | Example | | --- | --- | --- | | **Root** | Points to TLD servers | a.root-servers.net | | **TLD** | Points to authoritative servers | a.gtld-servers.net (.com) | | **Authoritative** | Has actual IP addresses | ns1.google.com | | **Recursive Resolver** | Does the work on behalf of clients | 8.8.8.8 (Google), 1.1.1.1 (Cloudflare) | ### NS Records Explained NS records are like address books at each level: * **Root NS records** → "These are the .com servers" * **TLD NS records** → "These are the microsoft.com servers" Each NS record is a delegation: "I don't handle this. Ask them." ### TTL (Time To Live) The TTL determines how long a DNS result can be cached: * Low TTL (300s) = Changes take effect quickly but more queries to authoritative servers * High TTL (86400s) = Fewer queries but slower propagation of changes ### dig Workflow When we run `dig microsoft.com`: 1. Our computer queries its configured resolver 2. If the resolver has the answer cached, it returns immediately 3. If not, the resolver performs the recursive resolution: * Queries root → Gets TLD server address * Queries TLD → Gets authoritative server address * Queries authoritative → Gets the IP address 4. Resolver caches the answer for TTL seconds 5. Resolver returns answer to us --- ## Conclusion DNS is one of the most elegant systems on the internet. Rather than centralized, it's distributed across thousands of servers. Rather than complex queries, it's based on simple delegation: "I don't know, ask them." The `dig` command is our window into this system. By understanding: * **What DNS is** (internet's address book) * **How it's hierarchical** (root → TLD → authoritative) * **What NS records do** (delegate to the next level) * **How recursive resolvers work** (do the legwork for us) * **How to use dig** (inspect each layer) We gain insight into one of the internet's fundamental technologies. The next time we visit a website, we can appreciate the thousands of DNS queries happening invisibly to make it work.