# How DNS Resolution Works ## TL;DR > **DNS (Domain Name System)** translates human-readable domain names into IP addresses so computers can locate servers. > `dig` command is a DNS troubleshooting tool used to query DNS servers and view DNS records. > It is used to **debug DNS issues, verify records, and understand DNS resolution**. > > * `dig . NS` shows the **root name servers** > > * `dig com NS` shows the **.com TLD name servers**. > > * `dig` [`google.com`](http://google.com) `NS` returns Google’s **authoritative name servers**. > > * `dig` [`google.com`](http://google.com) shows how DNS resolves a domain by going through > **Root → TLD → Authoritative servers**, returning the IP address used by the browser. > --- Have you ever stopped to think about how the internet actually works? Behind the simplicity of typing a web address and reaching a website in seconds lies a complex history. This seamless experience wasn’t always possible—it became a reality only after the creation of the Domain Name System (DNS), a foundational technology of the modern internet. ## What is DNS and why name resolution exists ### Domain Name System(DNS) DNS is the internet's phonebook. It translates human-readable website names into numerical, machine-readable IP addresses (like 192.168.1.1) that computers use to communicate over the internet. When you type a web address like [www.facebook.com](http://www.facebook.com) into your browser, DNS finds the matching IP address so your device can connect to the correct server. In simpler terms, you can think of DNS as asking, “**Whom to talk to next?**” ### Name Resolutions Existence Name resolution exists because the complex number-based IP addresses that computers use are hard for people to remember. Domain names are easier for users to recall. This makes using the internet simple, fast, and convenient for everyone. --- ## DNS Hierarchy DNS resolution happens in a **layered (hierarchical) process** so that the internet can stay organized and scalable. When you type a website address into your browser, your computer first checks with a **DNS resolver** to find the IP address. If the resolver doesn't already have the answer, it begins at the top of the DNS hierarchy. 1. **Root DNS servers** The resolver first queries a root server. Root servers don't know the exact IP address, but they know **where to find information about top-level domains** like `.com`, `.org`, or `.net`. The root server directs the resolver to the correct TLD server. 2. **TLD (Top-Level Domain) servers** Next, the resolver contacts the TLD server (for example, the `.com` server). The TLD server doesn't have the final IP address either, but it knows **which authoritative server is responsible** for the specific domain (like [`example.com`](http://example.com)). It guides the resolver to that server. 3. **Authoritative DNS servers** Finally, the resolver reaches out to the authoritative server. This server **has the actual IP address** for the domain and sends the correct IP address back to the resolver. Once the resolver gets the IP address, it sends it to your browser, which then connects to the website. This layered approach makes DNS fast, reliable, and able to support the entire internet. --- ### Behind the Scenes: How Recursive Resolvers Use DNS Information ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769191677322/63163b4f-f82c-4430-b84b-2851b4649cea.png align="center") A **recursive DNS resolver** plays a crucial role in the DNS hierarchy by handling domain name lookups on behalf of users. It quietly performs multiple steps in the background to find the correct IP address. 1. **Request initiated** → When you type a website address like [`www.google.com`](http://www.asample.com) into your browser, your device sends a DNS query to a recursive resolver to find the IP address of the domain. **Cache check** → The resolver first looks in its cache. If the domain was recently resolved, it quickly returns the IP address, saving time and reducing network traffic. If not then step 2 is processed. 2. **Query to the root server** → If the IP address isn't in the cache, the recursive resolver starts at the top of the DNS hierarchy by querying a **root name server**. Root servers don't store IP addresses but direct the resolver to the correct **Top-Level Domain (TLD) server** based on the domain extension (like `.com` or `.in`). 3. **Query to the TLD server** → The resolver then contacts the appropriate TLD server. The TLD server identifies which **authoritative name server** is responsible for the domain and provides that information. 4. **Query to the authoritative name server** → The recursive resolver reaches out to the authoritative server, which has the official DNS records. This server replies with the exact IP address of the domain. 5. **Returning the result** → The resolver sends the IP address back to your device, allowing your browser to connect to the website. It also stores the result in its cache for a limited time to speed up future requests. > **In summary**, recursive resolvers use cached data and the DNS hierarchy (root → TLD → authoritative) to efficiently resolve domain names without the user ever noticing the complexity behind the scenes. --- ## `dig` command `dig` stands for ***Domain Information Groper, is*** is a **DNS lookup tool** used to query DNS servers and retrieve detailed information about domain names. ### When `dig` is used The `dig` command is commonly used when: * **Troubleshooting DNS issues** (e.g., a website not loading) * **Checking DNS records** like A, AAAA, MX, NS, or TXT * **Verifying DNS configuration changes** * **Understanding the DNS resolution process** * **Testing name resolution from specific DNS servers** > The `dig` command is **not available everywhere by default**. On **Linux** and **macOS**, `dig` works **natively**. > > On **Windows**, it's a bit different. ***If you install the Windows Subsystem for Linux (WSL), you can get a real Linux environment inside Windows.*** ### NS records and why they matter **NS (Name Server) records** indicate the DNS servers that are **authoritative for a domain**. In simpler terms, they identify which servers are responsible for responding to DNS queries about that domain. NS records are important because DNS uses them to determine **where to send requests** when resolving a domain name. When someone looks up a website, DNS uses NS records to navigate through the hierarchy—from root servers, to TLD servers, and finally to the authoritative name servers. Without accurate NS records, DNS queries wouldn't reach the correct servers, making the domain inaccessible. > In simple terms, **NS records tell the internet who is in charge of a domain and ensure that users can reliably reach websites and services associated with it**. ### Uderstanding `dig . NS` and root name servers The command `dig . NS` is used to find the **name servers for the DNS root zone**. In DNS, the dot (`.`) represents the root of the entire domain name system. When you run this command, it asks DNS for the **NS (Name Server) records** of the root, which gives you a list of root name servers. **Root name servers** are the starting point for DNS resolution. They are at the top of the DNS hierarchy and don't store IP addresses for websites. Instead, they direct DNS queries to the correct **Top-Level Domain (TLD) servers**, like `.com`, `.org`, or `.net`. There are **13 logical root servers** and they are spread around the world to ensure speed and reliability. > In simple terms, `dig . NS` shows the servers that guide every DNS lookup on the internet, helping your system know where to start when resolving any domain name. ### Understanding `dig com NS` and TLD name servers The command `dig com NS` is used to find the **name servers for the** `.com` Top-Level Domain (TLD). In DNS, `.com` is a TLD, and NS (Name Server) records indicate which servers manage and respond to queries about domains ending in `.com`. **TLD name servers** are positioned just below the root name servers in the DNS hierarchy. They don't store the IP addresses of individual websites like [`google.com`](http://google.com), but they do know **which authoritative name servers** handle each `.com` domain. When a DNS query reaches a TLD server, it directs the request to the right authoritative server for that specific domain. > In simple terms, `dig com NS` shows the servers that control the `.com` domain and help route DNS queries to the correct authoritative name servers. ### Uderstanding `dig` [`google.com`](http://google.com) `NS` and authoritative name servers The command `dig` [`google.com`](http://google.com) `NS` is used to find the **authoritative name servers for the domain** [`google.com`](http://google.com). NS (Name Server) records show which DNS servers are officially responsible for managing the DNS records of a domain. **Authoritative name servers** are the final and most trusted source of DNS information for a domain. Unlike root or TLD servers, they **store the actual DNS records**, such as IP addresses (A/AAAA records), mail servers (MX records), and other settings for the domain. When a DNS query reaches an authoritative server, it provides the final answer. > In simple terms, `dig` [`google.com`](http://google.com) `NS` tells you which servers are in charge of [`google.com`](http://google.com) and provide its official DNS information. ### Uderstanding `dig` [`google.com`](http://google.com) and the full DNS resolution flow When you run `dig` [`google.com`](http://google.com), your system sends a DNS query to a **DNS resolver** (usually provided by your ISP or a public resolver like Google DNS). If the resolver already has the answer cached, it returns the IP address immediately. If not, it begins the DNS resolution process. First, the resolver queries a **root name server**, which points it to the appropriate **Top-Level Domain (TLD) server**, such as the `.com` TLD. Next, the resolver asks the **.com TLD server**, which responds with the **authoritative name servers** for [`google.com`](http://google.com). The resolver then queries one of these authoritative servers, which provides the final answer—the IP address of [`google.com`](http://google.com). Once the resolver receives the IP address, it sends it back to your system, and your browser uses it to connect to Google’s servers. The result is also cached to speed up future requests. In simple terms, `dig` [`google.com`](http://google.com) reveals how DNS moves step by step from the root to the authoritative server to find the correct IP address. ### DNS Resolution Workflow (`dig` [`google.com`](http://google.com)) ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769191863091/a228283a-15ad-4ff9-9119-d92a8a43186b.png align="center") 1. **User runs the command** * The user types `dig` [`google.com`](http://google.com). 2. **Query sent to DNS Resolver** * The system sends the query to a DNS resolver (ISP or public resolver). * The resolver checks its cache for [`google.com`](http://google.com). 3. **Query Root Name Server** * If not cached, the resolver asks a **root name server**. * The root server replies with the location of the **.com TLD name servers**. 4. **Query TLD Name Server (.com)** * The resolver queries a **.com TLD server**. * The TLD server responds with the **authoritative name servers for** [`google.com`](http://google.com). 5. **Query Authoritative Name Server** * The resolver queries one of Google’s **authoritative name servers**. * The authoritative server returns the **IP address for** [`google.com`](http://google.com). 6. **Response to User** * The resolver sends the IP address back to the user. * The result is cached for faster future lookups. 7. **Connection Established** * The browser uses the IP address to connect to Google’s server. --- ## Conclusion DNS is a fundamental part of how the internet works, allowing users to access websites using easy-to-remember domain names instead of numerical IP addresses. Through a hierarchical system involving root, TLD, and authoritative servers, DNS ensures efficient and reliable name resolution. Tools like `dig` make this process visible by allowing us to inspect each layer of DNS and understand how queries are resolved behind the scenes. Together, DNS and `dig` help demonstrate how a simple browser request is translated into a successful connection to a website. --- > If you enjoyed this article, check out my other blogs on this profile. > > 🔗 **Connect with me:** > [**LinkedIn**](https://linkedin.com/in/rajharsh4618) | [**GitHub**](https://github.com/Harsh-Raj4618) | [**X (Twitter)**](https://x.com/Harsh_Raj4618)