How DNS Really works and How it scales infinitely

07 Sep, 2025

Why should we care about DNS? Because it's one of the most beautiful pieces of software ever written - it made the internet what it is possible today by giving a human-readable name to every single thing out there, not requiring us to remember weird IP addresses of machines. But here's the thing: most people think DNS is just "domain name to IP address lookup." That's like saying the internet is just "computers talking to each other." The real story is way more interesting.

The Fundamental Problem DNS Solves

To connect to any machine on the internet, you need its IP address. When you type www.google.com in your browser, what your browser actually needs is the IP address to establish that TCP connection. But how do we discover that google.com → 17.53.21.253?

So there would be a place where this mapping is stored - somewhere this particular mapping needs to be configured: www.google.com means 17.53.21.253. This is typically the A record or the CNAME record in the DNS configuration.

Why do we need DNS records at all? Because we need to store different types of mappings, not just domain-to-IP.

A Record - Maps a domain name directly to an IPv4 address:

www.google.com → 17.53.21.253

CNAME Record - Maps a domain name to another domain name (alias):

blog.google.com → www.google.com

Think of CNAME as a redirect. When someone looks up blog.google.com, DNS says "actually, go look up www.google.com instead."

DNS Zones: The Logical Foundation

A DNS Zone is like a database table that contains all the DNS records for a particular domain and its subdomains.

Example zone file for google.com:

google.com.        A      17.53.21.253
www.google.com.    A      17.53.21.253  
mail.google.com.   A      74.125.224.83
blog.google.com.   CNAME  www.google.com

Why zones? Organization and delegation. Google manages everything under google.com in their zone, while university.edu manages their own zone separately.

Cloud Providers:

AWS Route 53 - Amazon's DNS service
Google Cloud DNS - Google's DNS service
Azure DNS - Microsoft's DNS service
Cloudflare DNS - Also provides CDN services

Traditional DNS Providers:

GoDaddy DNS - Comes free with domain registration
Namecheap DNS - Free with domains
DNSimple - Paid DNS hosting specialist
NS1 - Enterprise DNS provider

Free Options:

Cloudflare - Free tier available
Hurricane Electric - Free DNS hosting

If you're using AWS, you'd configure this in Route 53 as a hosted zone. This zone contains everything about google.com - all the mappings, all the subdomains, all the different record types.

Authoritative Name Servers: The Source of Truth

Authoritative Name Server = The server that actually stores and serves your DNS zone data.

Zones are served via Authoritative Name Servers. An authoritative name server hosts multiple zones, and it answers DNS questions for the zones it owns.

These servers typically look like ns1.gns.com, ns2.gns.com, ns3.gns.com - usually offered by cloud providers like GoDaddy, Namecheap, or AWS. When you buy a domain, you configure which name servers should handle it.

Here's the key insight: if you somehow know the authoritative name server's address, you can get the record you're looking for. But how does your browser know which name server to ask?

The Two Approaches: Centralized vs Decentralized

Let's think about this problem. How would we reach these authoritative name servers?

Option 1: The Centralized Database

Let there be a single massive "database" system that everybody reaches out to when they want DNS information.

This centralized way is not scalable, fault tolerant, or even manageable. Think about the concerns: volume of data, number of requests and updates, and any change in any info needs to be communicated to this single system.

If this goes down, the entire internet is down. The sheer volume of requests it would need to handle and the amount of data it would need to store makes this approach impossible.

Option 2: Decentralized Approach - No One Machine Knows It All

This is where the beauty of DNS architecture comes in. The world went with decentralization where no single machine knows everything.

DNS Resolvers: Your Gateway to the System

DNS Resolver is a server that carries out the resolution of Domain Name to IP address. Where does this DNS resolver run?

Typically runs at ISP, but you can run your own locally. Most home routers are real DNS resolvers. You can check yours by running:

ipconfig /all    # Windows
# Look for DNS Servers entry

On my machine, I get 192.168.0.1 - that's my router doing DNS resolution for me. You can change this to popular DNS resolvers like:

Google: 8.8.8.8
Cloudflare: 1.1.1.1

Root Name Servers: The Foundation of the Internet

Think about this chicken-and-egg problem: To find any website, you need to ask a DNS server. But how do you find the DNS server's address? You'd need DNS to find DNS!

Root Name Servers solve this bootstrap problem. They're the "starting point" that everyone agrees on.

Here's where it gets really interesting. Say we are looking for www.google.com - we need to reach its Authoritative Name Server, but we do not know where it is!

13 Root Name Servers

Calls to Root NS are infrequent, because even IP of TLD (Top-Level-Domain) servers does not change often, so it is heavily cached.

The Complete DNS Resolution Process

Now, how does the DNS resolution process actually work? Let's walk through it step by step, assuming nothing is cached:

Putting It All Together

You buy mysite.com from GoDaddy (registrar)
GoDaddy registers your domain with .com TLD servers
By default, GoDaddy's name servers become authoritative for your zone
You can change to use AWS Route 53 instead
Your DNS zone contains A records, CNAME records, etc.

Step by Step Resolution

1. Query to Root Name Server When queried for Domain Name, it responds with IP address of server handling the TLD (e.g., .com, .in, .edu, etc.)

2. Query to TLD Server The .com TLD server responds with the authoritative name server that owns the zone google.com

3. Query to Authoritative Name Server Because it owns the corresponding zone, it can respond with what's configured against www.google.com, which is the IP address 17.53.21.253

4. Browser Connection Your browser gets the IP address, establishes TCP connection to the load balancer, sends HTTP request, gets response - and that's how you see Google's homepage.

The Caching Strategy: How DNS Scales Infinitely

Here's the secret sauce: each machine takes us closer to machine that knows it.

Denotes caching - This information is cached for a few hours across multiple layers:

The recursion continues from Google Name Server to Authoritative Name Server of domain zone google.com. Then it checks the record against www, which may point to a load balancer, and it then resolves to the IP of the load balancer.

Key insight: The beauty of DNS is that it's a step-by-step resolution process. You go to .com TLD, they give you google.com authority, you go to that and say "Give me www.google.com" - it's hierarchical resolution that scales infinitely.

Why This Architecture Is Brilliant

The DNS architecture solves several critical problems:

Infinite Scalability - No single point of failure, distributed globally with heavy caching at every layer.

Fault Tolerance - Multiple servers at each level, anycast distribution, and redundant authoritative name servers.

Human Usability - We remember google.com instead of 17.53.21.253.

Decentralized Management - Organizations control their own zones without depending on a central authority.

Performance - Heavy caching means most DNS lookups never leave your local network.

This is one of those systems where the more you understand it, the more you appreciate how elegantly it solves an impossibly complex global coordination problem. The fact that typing any domain name anywhere in the world just works - that's the magic of DNS.

Note: In upcoming content, I'll be building my own DNS server to show you exactly how this protocol works under the hood.