How DNS Resolution Works
What Is DNS And How It Works
DNS stands for Domain Name System. Without this, we can’t access anything in internet. Let’s understand what it really does and concepts related to this technology.
Often times, we don’t remember contact number of people. When we want to calls someone, we would search their name in our contact list then we will call them. Here, by utilizing contact list of multiple people with their name and number, we are solving the complexity of having to remember number of people which is hard for us as compared to remembering their name.
Just like a phone number belongs to only one person and the phone number becomes point of contact to the person, websites also have an unique IP address through which we can access them through the internet. IP address is the point of contact for us to access the websites. But you may wonder that you never see IP address when you enter a website name.
Just like how a contact list in our phone has ability to get number of person by searching their name, DNS helps us find the IP address of the website using domain names.
Unlike a contact list sitting on our phone, DNS is a global service which is responsible for finding IP address of all the websites. This process look up process is called name resolution.
Now that we know what is DNS is and what is does, let’s try to understand how we can practically inspect how it really works.
DNS Resolution Layers
While DNS in simpler terms may seem like a simple give and take like process for domain name and IP address lookup, it is actually more complex and layered process. Each process doing a specific task, a DNS call takes multiple trips before finishing up the look up process.
The flow always follow the following pattern: Root → TLD → Authoritative Servers → Resolution
Let’s understand the steps one by one
Root layer
This is the first layer of the DNS query. It doesn’t have any data related to the domain and it’s respective IP address. Instead, it will have data TLD (Top level domains: .com, .org, .cloud, .ai) managers.
There are only 13 logical root server clusters spanning from a to m logical addresses. The DNS providers fork the logical root server cluster and create their own root serer resolver. Once the root layer will figure out who is managing the TLD of the requested domain, the flow moves to TLD Layer.
TLD Layer
The TLD layer also doesn’t hold any data about the domain and it’s IP address. Instead, it holds data about which authoritative servers manage each domain under the TLD. Once the authoritative server of the TLD is figured out, flow is then moved to authoritative servers.
Authoritative Servers
Once TLD layer figures out the respective authoritative server for the domain of the TLD, flow moves to the authoritative server which holds the source of truth about record of the domain. The authoritative server will then find out the A record of the domain which holds the IPV4 of the domain.
The authoritative server is where the DNS lookup will be resolved. It will get the A record of the domain which is nothing but IPV4 address of the server which is being pointed by a domain.
Inspecting DNS resolution with dig
dig is a diagnostic tool to inspect DNS resolution. It is a command line utility tool which can be used to send raw DNS query to a DNS server and get the response back. It is often used to check and validate any updates related to DNS records. It is available out of the box on Linux systems.
Understanding Usage Of Different dig Commands
Now that we know why dig is used, let’s try to understand different ways we can utilize it and understand it’s use cases. It comes with various usages. Based on different type of usages, we can utilize it in various ways.
Let’s explore different commands utilizing the dig command considering the same flow of DNS resolution we discussed above. Which is, Root → TLD → Authoritative servers → result
We will be referencing to google.com for the reference of domain name for all the examples.
Understanding Root of DNS with dig . NS
command:
dig . NS google.com
This command queries for root name servers of the root of DNS which are entry point for all the DNS resolution/lookup processes also referenced as Root. Root only holds data about the server which manages the TLD (Top Level Domain). The . in the command represents the DNS root zone.
example: Querying for root name servers for google.com
Notice how there are exactly 13 name servers listed, those are the universal logical group of root name servers.
➜ ~ dig . NS google.com
; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> . NS google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6445
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 7180 IN NS k.root-servers.net.
. 7180 IN NS c.root-servers.net.
. 7180 IN NS d.root-servers.net.
. 7180 IN NS e.root-servers.net.
. 7180 IN NS i.root-servers.net.
. 7180 IN NS m.root-servers.net.
. 7180 IN NS j.root-servers.net.
. 7180 IN NS a.root-servers.net.
. 7180 IN NS l.root-servers.net.
. 7180 IN NS f.root-servers.net.
. 7180 IN NS b.root-servers.net.
. 7180 IN NS h.root-servers.net.
. 7180 IN NS g.root-servers.net.
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Jan 27 22:24:11 IST 2026
;; MSG SIZE rcvd: 239
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63183
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 203 IN A 142.250.205.110
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Jan 27 22:24:11 IST 2026
;; MSG SIZE rcvd: 55
Understanding TLD name servers dig com NS
command:
dig com NS google.com
This command queries for name servers responsible to resolve for the TLD of the requested domain. Since we are querying for google.com, it will list out the authoritative name servers which are responsible for resolving .com TLD. These name servers don’t hold any data records related to the TLD. It only knows only which authoritative manages each .com domain.
example: Querying for NS (name servers) records for google.com
Notice how there name servers listed for
.comunlike.which was received from the root DNS query
➜ ~ dig com NS google.com
; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> com NS google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6740
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;com. IN NS
;; ANSWER SECTION:
com. 21599 IN NS i.gtld-servers.net.
com. 21599 IN NS b.gtld-servers.net.
com. 21599 IN NS f.gtld-servers.net.
com. 21599 IN NS h.gtld-servers.net.
com. 21599 IN NS j.gtld-servers.net.
com. 21599 IN NS g.gtld-servers.net.
com. 21599 IN NS e.gtld-servers.net.
com. 21599 IN NS c.gtld-servers.net.
com. 21599 IN NS l.gtld-servers.net.
com. 21599 IN NS a.gtld-servers.net.
com. 21599 IN NS m.gtld-servers.net.
com. 21599 IN NS k.gtld-servers.net.
com. 21599 IN NS d.gtld-servers.net.
;; Query time: 52 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Jan 27 22:40:47 IST 2026
;; MSG SIZE rcvd: 256
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60663
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 210 IN A 142.250.205.110
;; Query time: 9 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Jan 27 22:40:47 IST 2026
;; MSG SIZE rcvd: 55
Understanding Authoritative Name Servers With dig <domain> NS
command:
dig google.com NS
This command queries for authoritative server which resolves NS records for google.com. These servers are operated by google. Theser severs are the source of truth for google.com. It identifies where different type of DNS records lives but it doesn’t return the IP address of the site.
example: Querying for authoritative name servers records for google.com
Notice how instead of top level domain, it now includes the domain address and respective name server which holds different records to resolve the domain
; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> google.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 201
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com. IN NS
;; ANSWER SECTION:
google.com. 9394 IN NS ns1.google.com.
google.com. 9394 IN NS ns2.google.com.
google.com. 9394 IN NS ns3.google.com.
google.com. 9394 IN NS ns4.google.com.
;; Query time: 16 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Jan 27 22:59:16 IST 2026
;; MSG SIZE rcvd: 111
Understanding Full DNS Resolution Flow With dig <domain>
command:
dig google.com
This command will perform full DNS resolution and gets back A record (IPV4) of the domain. It will perform all the recursive resolution and returns back the A record of the domain from the respective authoritative servers. In our case, it query for IPV4 of google.com from google authoritative servers.
example: full DNS resolution flow of google.com
Notice how we got an A record (IPV4) of
google.com, that’s the result part of the DNS resolve cycle.
➜ ~ dig google.com
; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42676
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 96 IN A 142.251.223.14
;; Query time: 10 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Jan 27 23:01:53 IST 2026
;; MSG SIZE rcvd: 55
Conclusion: Order Of dig commands:
Each command reveals one layer:
dig . NS→ Root serverdig com NS→ TLD NSdig google.com NS→ Authoritative NSdig google.com→ End result after all layers
NS And It’s Importance
NS stands for Name Server. It is one of the critical part of DNS resolution. It holds information about the sever which is responsible for the domain. Which means, A NS record does not store IP addresses of websites. It stores names of DNS servers that are responsible to answer for a domain.
DNS is not a database. It is rather a reference system to find who has authority to store what information of the domain. It defines boundary and authority of:
Who is allowed to make requests to domain
Who’s responsibility spans from where to where
Who holds the reference of next reference.
Example: NS for google servers looks like following:
google.com NS ns1.google.com
google.com NS ns2.google.com
NS records drive this process:
Root NS records: Say who manages TLD( .com, .org, etc).
TLD NS records: Say who manages domains (google.com, amazon.com, etc.)
Domain NS records: Say which servers are authoritative for that domain