DNS: how It All Works
Ever wondered how DNS resolves domain names? How does it work behind the scenes? Well, in this blog, I’ll take you on a fun ride through the magical world of DNS resolution. Whether it’s Google’s famous 8.8.8.8 or Cloudflare’s 1.1.1.1, you’ll finally understand what’s happening when you type a domain into your browser.
DNS: Your Internet’s Phonebook 📖
DNS (Domain Name System) is basically the internet’s way of giving websites easy to remember names instead of expecting you to memorize IP addresses (because let’s be honest, no one remembers 172.217.14.206). No matter how often an IP address changes, you only need to remember the domain name, and DNS takes care of the rest.
So… Who’s Running This Show? Now, you might be wondering—who owns and manages this whole system? Enter the 13 root servers! These servers form the backbone of the DNS hierarchy, ensuring your domain queries don’t get lost in the void. They are managed by non-profit organizations and overseen by the Internet Corporation for Assigned Names and Numbers (ICANN). These root servers are scattered across the globe, with different organizations handling them on behalf of ICANN. They are officially recognized as 13 named authorities in the DNS root zone. Want to meet these DNS superheroes? Check out the full list of root servers along with their operators here.
| Root Server | IPv4 Address(es) | IPv6 Address(es) | Operator |
|---|---|---|---|
| a.root-servers.net | 198.41.0.4 | 2001:503:ba3e::2:30 | Verisign, Inc. |
| b.root-servers.net | 170.247.170.2 | 2801:1b8:10::b | University of Southern California, Information Sciences Institute |
| c.root-servers.net | 192.33.4.12 | 2001:500:2::c | Cogent Communications |
| d.root-servers.net | 199.7.91.13 | 2001:500:2d::d | University of Maryland |
| e.root-servers.net | 192.203.230.10 | 2001:500:a8::e | NASA (Ames Research Center) |
| f.root-servers.net | 192.5.5.241 | 2001:500:2f::f | Internet Systems Consortium, Inc. |
| g.root-servers.net | 192.112.36.4 | 2001:500:12::d0d | US Department of Defense (NIC) |
| h.root-servers.net | 198.97.190.53 | 2001:500:1::53 | US Army (Research Lab) |
| i.root-servers.net | 192.36.148.17 | 2001:7fe::53 | Netnod |
| j.root-servers.net | 192.58.128.30 | 2001:503:c27::2:30 | Verisign, Inc. |
| k.root-servers.net | 193.0.14.129 | 2001:7fd::1 | RIPE NCC |
| l.root-servers.net | 199.7.83.42 | 2001:500:9f::42 | ICANN |
| m.root-servers.net | 202.12.27.33 | 2001:dc3::35 | WIDE Project |
Alright, Let’s Get Technical! 🚀
First things first always remember, domains start with a dot (.). Wait, what? A dot? Yes, you read that right! Domains begin with a root dot (.), even though we usually don’t see it. For example, the actual fully qualified domain name (FQDN) for example blog.0xmm.in is blog.0xmm.in. (notice the trailing dot). Each dot (.) in a domain name is like a hierarchy separator, as defined in RFC 1034.
DNS: The Internet’s Dictionary 📖
Every domain and its corresponding IP address are stored as key-value pairs, much like a dictionary. So, what happens when you type google.com into your browser?
Your browser first tries to resolve the domain name into an IP address. It asks a recursive DNS server (like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1), which keeps a cache of previously resolved domains.
If the recursive resolver doesn’t have the answer, it asks authoritative servers until it finds the correct IP address.
Most of the time, your ISP provides a recursive DNS server, but you can also use public resolvers like 1.1.1.1, 8.8.8.8, or 8.8.4.4.
devtest@devtest:~$ dig @8.8.4.4 0xmm.in
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @8.8.4.4 0xmm.in
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30615
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;0xmm.in. IN A
;; ANSWER SECTION:
0xmm.in. 1799 IN A 103.95.113.73
;; Query time: 85 msec
;; SERVER: 8.8.4.4#53(8.8.4.4) (UDP)
;; WHEN: Sat Feb 01 17:44:55 UTC 2025
;; MSG SIZE rcvd: 100
So, you ran a DNS query, and boom! The ANSWER SECTION shows the IP address for the domain you requested. But how does this actually work? How does a recursive resolver magically know which IP belongs to a domain?
Well, here’s the twist—resolvers don’t actually store domain to IP mappings. They’re just messengers that fetch answers from DNS’ massive distributed database, which is maintained by nameservers.
Think of the DNS namespace as a giant tree 🌳, where each nameserver is responsible for a specific branch (subtree). These subdivisions are called zones, and each zone has an authoritative nameserver that holds the official records for that part of the tree.
Resolvers just ask around, climbing the DNS tree from root servers down to the authoritative nameserver until they find the IP address you need. Simple, right? 🚀
Recursive resolvers also have to navigate this DNS tree to find the right answer but they start at the very top: the root node (.). At the highest level of DNS, there are 13 root nameservers that hold authority over the root zone (.). These root servers have well-known IP addresses, acting as the backbone of the entire DNS resolution process.
Any given domain has a single unique path through this tree, starting at any node and walking up to the root. Here’s 0xmm.in, for example:
Think of them as the ultimate librarians of the internet if they don’t know the answer, they’ll at least point you in the right direction! 📚✨
Recursive Resolution By Hand
Let’s see if we can resolve 0xmm.in by walking this tree manually, starting at one of these root servers:
devtest@devtest:~$ dig @m.root-servers.net 0xmm.in
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @m.root-servers.net 0xmm.in
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 928
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;0xmm.in. IN A
;; AUTHORITY SECTION:
in. 172800 IN NS ns2.registry.in.
in. 172800 IN NS ns1.registry.in.
in. 172800 IN NS ns4.registry.in.
in. 172800 IN NS ns5.registry.in.
in. 172800 IN NS ns6.registry.in.
in. 172800 IN NS ns3.registry.in.
;; ADDITIONAL SECTION:
ns6.registry.in. 172800 IN A 156.154.101.20
ns5.registry.in. 172800 IN A 156.154.100.20
ns4.registry.in. 172800 IN A 37.209.198.12
ns3.registry.in. 172800 IN A 37.209.196.12
ns2.registry.in. 172800 IN A 37.209.194.12
ns1.registry.in. 172800 IN A 37.209.192.12
ns6.registry.in. 172800 IN AAAA 2001:502:ad09::20
ns5.registry.in. 172800 IN AAAA 2001:502:2eda::20
ns4.registry.in. 172800 IN AAAA 2001:dcd:4::12
ns3.registry.in. 172800 IN AAAA 2001:dcd:3::12
ns2.registry.in. 172800 IN AAAA 2001:dcd:2::12
ns1.registry.in. 172800 IN AAAA 2001:dcd:1::12
;; Query time: 19 msec
;; SERVER: 202.12.27.33#53(m.root-servers.net) (UDP)
;; WHEN: Sun Feb 02 07:09:48 UTC 2025
;; MSG SIZE rcvd: 419
The root nameserver didn’t give us an answer—notice the missing ANSWER SECTION. Instead, it pointed us to the nameservers responsible for the .in zone under the AUTHORITY SECTION.
These authoritative nameservers manage .in domains, so our next step is to ask one of them: “Hey, do you know the IP address for 0xmm.in?”
Let’s see if they have the answer! 🔍✨
devtest@devtest:~$ dig @156.154.101.20 0xmm.in
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @156.154.101.20 0xmm.in
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29155
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0b1dd5e8959e861701000000679f1aa9eb991145a22cf1f6 (good)
;; QUESTION SECTION:
;0xmm.in. IN A
;; AUTHORITY SECTION:
0xmm.in. 3600 IN NS dns1.registrar-servers.com.
0xmm.in. 3600 IN NS dns2.registrar-servers.com.
;; Query time: 26 msec
;; SERVER: 156.154.101.20#53(156.154.101.20) (UDP)
;; WHEN: Sun Feb 02 07:11:37 UTC 2025
;; MSG SIZE rcvd: 123
Still no ANSWER SECTION, but we’re making progress! The authoritative nameserver for the .in zone has now pointed us to the nameservers responsible for 0xmm.in.
Looks like we need to dig one level deeper, let’s keep going! 🔍🚀
devtest@devtest:~$ dig @dns1.registrar-servers.com 0xmm.in
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @dns1.registrar-servers.com 0xmm.in
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55813
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0xmm.in. IN A
;; ANSWER SECTION:
0xmm.in. 1799 IN A 103.95.113.73
;; AUTHORITY SECTION:
0xmm.in. 1800 IN NS dns1.registrar-servers.com.
0xmm.in. 1800 IN NS dns2.registrar-servers.com.
;; Query time: 26 msec
;; SERVER: 156.154.132.200#53(dns1.registrar-servers.com) (UDP)
;; WHEN: Sun Feb 02 07:12:21 UTC 2025
;; MSG SIZE rcvd: 159
After following the DNS trail, we finally get an ANSWER SECTION, revealing that 103.95.113.73 is the IP address for 0xmm.in. 🎯
Now, let’s double-check our results by asking a well-known recursive resolver—just to make sure we didn’t get lost along the way! 🔍🚀
devtest@devtest:~$ dig +short @1.1.1.1 0xmm.in
103.95.113.73
With no prior caching, the only IPs we know are those of the root servers. So, our journey begins at the top!
From there, we recursively work our way down, following the DNS hierarchy step by step, until we reach the authoritative nameserver for the zone where our target domain lives.
Think of it like a treasure hunt each server hands us a clue, leading us closer to the final answer!
Wrapping Up
I hope this guide has given you a clearer picture of how DNS resolution works behind the scenes, from the root servers all the way to the final IP address. Now you’re equipped with the knowledge to understand how domains find their way on the internet.
Feel free to dig deeper into DNS or share this with anyone who might need a little help understanding how the magic happens.