# How DNS Resolution Works When we open a website like [google.com](http://google.com), it feels instant. We type a name, press Enter, and the page loads. What we don’t see is the long chain of systems working behind the scenes to convert that human friendly name into something computers actually understand. This is where DNS comes in. DNS is one of those systems every web developer uses every day, often without realising it. To truly understand how the web works, we must understand DNS, not just definitions, but how it behaves in the real world. In this article, we will break DNS down step by step and use the dig command to build a clear mental model of how name resolution actually happens. ## **What is DNS and why name resolution exists** Computers do not understand domain names. They communicate using IP addresses, which are numeric values like 142.250.190.14. Humans, however, cannot easily remember numbers, especially at the scale of the internet. DNS (Domain Name System) exists to solve this exact problem. We can think of DNS as the internet’s phonebook. Instead of memorising IP addresses, we remember names like [google.com](http://google.com). DNS acts as the translation system that maps these names to their corresponding IP addresses. Without DNS, the web would still work, but it would be unusable for humans. Every website visit would require remembering and typing raw IP addresses. DNS makes the web usable, scalable, and human friendly. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769749935961/ed294bbf-9ad9-42a3-a05d-9cbf5479e741.png align="center") --- ## **What is the dig command and when it is used** dig stands for Domain Information Groper. It is a command line tool used to query DNS servers directly and inspect DNS records. Browsers perform DNS lookups automatically, but they hide the details from us. dig removes that abstraction. It allows us to ask very specific DNS questions and see exactly which server responds and what information is returned. We typically use dig when: * Debugging DNS issues * Understanding how DNS resolution flows * Verifying DNS records like NS, A, MX, TXT * Learning how DNS works internally In short, dig is not just a tool, it is a lens into the DNS system. --- ## **Understanding dig . NS and root name servers** Let’s start at the very top of DNS. When we run: ```xml dig . NS ``` We are asking: “Who is responsible for the root of the DNS system?” The dot (.) represents the DNS root zone. Root name servers do not know IP addresses for domains like [google.com](http://google.com). Instead, they know where to find information about top level domains such as .com, .org, .net, and country codes like .in. Root servers are the first step in DNS resolution. They act like a directory that says, “I don’t know the final answer, but I know who might.” ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769750100823/db7e8112-fcb6-41b9-9306-893f2acdb071.png align="center") There are total 13 Root servers in the world, but total 1600+ implementations, means there are 1600+ copies present in the world. This is an important concept: DNS works by referral, not by guessing. --- ## **Understanding dig com NS and TLD name servers** Next, we move one level down the hierarchy. When we run: ```xml dig com NS ``` We are asking: “Which name servers are responsible for the .com domain?” These servers are called TLD (Top Level Domain) name servers. TLD servers do not know the IP address of [google.com](http://google.com). Instead, they know which authoritative name servers are responsible for domains under .com. So again, we see the same pattern: * Root → points to TLD * TLD → points to authoritative servers DNS is intentionally layered to remain scalable across billions of domains. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769750335053/312161c8-cf8e-40a0-98f7-0c07344ff735.png align="center") This output shows the result of running dig com NS, which asks DNS who is responsible for the .com top level domain. The important part is the ANSWER SECTION. It lists multiple NS (Name Server) records like [a.gtld-servers.net](http://a.gtld-servers.net), [b.gtld-servers.net](http://b.gtld-servers.net), and so on. These are the official TLD name servers for .com, and they are managed by the .com registry. The number 172800 is the TTL (time to live), which means resolvers can cache this information for about 2 days. This output does not give IP addresses for websites like [google.com](http://google.com); instead, it tells DNS resolvers where to go next to find which authoritative name servers handle a specific .com domain. --- ## **Understanding dig** [**google.com**](http://google.com) **NS and authoritative name servers** When we run: ```xml dig google.com NS ``` We are asking: “Which name servers are authoritative for [google.com](http://google.com)?” Authoritative name servers are the source of truth for a domain. They are configured by the domain owner (or their DNS provider). These servers contain the actual DNS records A, AAAA, MX, TXT, and more. Once a resolver reaches the authoritative name server, it can finally ask: > `“What is the IP address for` [`google.com`](http://google.com)`?”` **And this server gives the final answer.** ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769750380840/e0df5fb1-b195-424e-8e47-f8a7cab6bb5c.png align="center") This output shows the result of running dig [google.com](http://google.com) NS, which asks DNS which name servers are authoritative for the [google.com](http://google.com) domain. In the ANSWER SECTION, we see four NS records: [ns1.google.com](http://ns1.google.com), [ns2.google.com](http://ns2.google.com), [ns3.google.com](http://ns3.google.com), and [ns4.google.com](http://ns4.google.com). These are Google’s authoritative name servers, meaning they are the final source of truth for all DNS records of [google.com](http://google.com). The TTL value (270971) tells resolvers how long this information can be cached. The ADDITIONAL SECTION includes the actual IP addresses (both IPv4 A and IPv6 AAAA) of these name servers, so resolvers can contact them directly without doing another lookup. At this stage of DNS resolution, the system now knows exactly where to ask for the final IP addre**ss of** [**google.com**](http://google.com)**.** --- ## **Understanding dig** [**google.com**](http://google.com) **and the full DNS resolution flow** Now let’s connect everything. When we run: ```xml dig google.com ``` dig performs the full lookup and shows us the final DNS response. But behind the scenes, the resolution followed a clear path: 1. Ask root name servers where .com lives 2. Ask .com TLD servers where [google.com](http://google.com) lives 3. Ask Google’s authoritative servers for the IP address 4. Receive the final answer This entire process usually happens in milliseconds. In real life, browsers don’t talk directly to root or TLD servers. They use recursive resolvers (usually provided by ISPs or public services like Google DNS). These resolvers perform all the steps on our behalf and cache results to make future lookups faster. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769750434383/5f7c0e08-d1d9-4941-8c86-95624e0ea202.png align="center") This output shows the final step of DNS resolution. The command dig [google.com](http://google.com) asks for the A record of [google.com](http://google.com), which means we are now asking for the actual IP address to connect to. In the ANSWER SECTION, DNS returns 172.217.27.174, which is one of Google’s server IPs. The TTL value (107) is very small, showing that Google keeps this record short lived so traffic can be routed dynamically. At this point, DNS resolution is complete, the browser now has a concrete IP address and can open a network connection to Google’s servers. --- ## **What NS records represent and why they matter** NS (Name Server) records define who controls a domain’s DNS. They are critical because: * They define authority * They enable delegation * They allow DNS to scale globally Without NS records, DNS would have no way to know where responsibility for a domain begins and ends. Whenever we change DNS providers, what we are really doing is changing NS records. **How recursive resolvers use this information behind the scenes** Recursive resolvers are like professional DNS investigators. They: * Query root servers * Follow referrals to TLD servers * Reach authoritative servers * Cache responses using TTL values This caching is why DNS lookups are fast most of the time and slow only on first access. Resolvers hide complexity, but dig exposes it, making DNS understandable instead of mysterious. ---