Hi Pythonistas!
You type parseltongue.co.in in your browser.
A page loads.
But your browser never actually uses that name to find the server.
The internet doesn't understand names.
It only understands numbers.
IP addresses.
Like 104.21.3.45.
So something needs to translate:
parseltongue.co.in → 104.21.3.45
That something is DNS.
Domain Name System.
Why DNS Exists
In the early internet - very few computers existed.
Every computer had a file called hosts.txt.
It contained every name to IP mapping in the world.
192.168.1.1 mit.edu
192.168.1.2 stanford.edu
192.168.1.3 darpa.mil
You downloaded this file periodically.
Works fine for 100 computers.
Then the internet grew.
Millions of computers.
Billions of domains.
A single file couldn't work anymore.
DNS was invented in 1983 to replace it.
Distributed. Scalable. Automatic.
You still have a hosts.txt on your computer today:
cat /etc/hosts # Linux/MacIt's checked before DNS.
Developers use it to override domains locally.
DNS Is a Hierarchy
DNS is not one server.
It's a tree of servers.
Root (.)
/ | \
.com .in .org
\
parseltongue.co.in
Three levels:
Root servers
13 sets of root servers worldwide.
They don't know your domain directly.
They know who does.
TLD servers
Top Level Domain.
.com, .in, .org, .net
They know where every domain under them lives.
Authoritative nameservers
The final authority for your domain.
Knows the actual IP.
Your domain registrar sets this up.
Wait .co.in Has Two Parts?
Good question.
parseltongue.co.in breaks down like this:
parseltongue → your domain name
co → second level domain
in → the actual TLD
.in is India's country code TLD.
Many countries add structure underneath:
.co.in → commercial India
.gov.in → government India
.ac.in → universities India
.mil.in → military India
So .co.in together acts like a TLD in practice.
But in the DNS hierarchy:
Root
↓
.in (TLD — India)
↓
.co.in (managed by NIXI — India's internet registry)
↓
parseltongue.co.in (your authoritative nameserver)
Anyone visiting a .gov.in domain immediately knows:
official Indian government site.
Trust signal built into the domain itself.
The Full DNS Resolution
You type parseltongue.co.in.
Here's exactly what happens:
Step 1 - Browser cache
Visited before?
Answer already stored.
Done. No network needed.
Step 2 - OS cache
Not in browser cache?
OS checks its own cache.
Also checks /etc/hosts.
Step 3 - DNS Resolver
Not cached anywhere?
OS asks the DNS Resolver.
Usually your ISP's DNS server.
Or a public one:
8.8.8.8 → Google DNS
1.1.1.1 → Cloudflare DNS
The resolver is like a librarian.
You ask a question.
It goes and finds the answer.
Step 4 - Resolver asks Root server
Resolver doesn't know parseltongue.co.in.
Asks a Root server:
"Who handles .in domains?"
Root server: "Go ask this TLD server."
Step 5 - Resolver asks TLD server
Asks the .in TLD server:
"Who handles parseltongue.co.in?"
TLD server: "Go ask this authoritative nameserver."
Step 6 - Resolver asks Authoritative nameserver
"What is the IP for parseltongue.co.in?"
Authoritative nameserver: "It's 104.21.3.45."
Step 7 - Answer returns
Resolver sends IP back to OS.
OS sends it to browser.
Browser caches it.
Browser connects to 104.21.3.45.
Full flow:
Browser
↓ check cache
OS
↓ check cache + /etc/hosts
DNS Resolver
↓
Root Server → "ask .in TLD"
↓
TLD Server → "ask authoritative nameserver"
↓
Authoritative Nameserver → "IP is 104.21.3.45"
↓
Resolver → returns IP
↓
Browser connects
This whole journey typically under 50 milliseconds.
DNS Records
DNS doesn't just store IP addresses.
It stores different types of records.
A Record
Domain to IPv4 address.
parseltongue.co.in → 104.21.3.45
Most common record.
AAAA Record
Domain to IPv6 address.
parseltongue.co.in → 2606:4700:3037::ac43:d9b6
CNAME Record
Domain to another domain.
An alias.
www.parseltongue.co.in → parseltongue.co.in
www points to root domain.
Root domain has the A record.
MX Record
Where to send emails for this domain.
parseltongue.co.in → mail.google.com
TXT Record
Arbitrary text.
Used for:Domain verification
SPF records (email security)
DKIM keys
NS Record
Which nameservers are authoritative for this domain.
parseltongue.co.in → ns1.cloudflare.com
TTL
Every DNS record has a TTL.
Time To Live.
parseltongue.co.in A 104.21.3.45 TTL: 3600
TTL = 3600 means:
cache this answer for 3600 seconds.
One hour.
After that - ask again.
Why this matters:
You move your site to a new server.
New IP: 172.67.201.182.
You update the DNS record.
But everyone who cached the old IP keeps using it.
For up to TTL seconds.
This is called DNS propagation.
Can take minutes to 48 hours.
Best practice before migration:
Normal: TTL = 86400 (24 hours)
Before migration: TTL = 300 (5 minutes)
After migration: TTL = 86400 (back to normal)
Lower it early.
Change IP.
Recovery is fast if something goes wrong.
Raise it back after.
DNS Uses UDP
Remember Post 2A?
DNS uses UDP.
Why?
DNS query = tiny question. DNS response = tiny answer.
One packet out. One packet back.
No need for a full TCP handshake.
Fast.
But if the response is too large:
DNS falls back to TCP automatically.
DNS Caching - Multiple Layers
DNS answers get cached everywhere:
Browser cache → fastest, checked first
OS cache → second
DNS Resolver cache → third
Most queries never reach the root servers.
Answered from cache.
Root servers handle billions of queries per day.
Without caching - impossible.
DNS in System Design
DNS is not just for browsers.
In system design it becomes a powerful tool.
Load balancing
One domain. Multiple IPs.
parseltongue.co.in → 104.21.3.45
parseltongue.co.in → 172.67.201.182
parseltongue.co.in → 198.41.214.162
DNS returns different IPs in rotation.
Each user hits a different server.
This is DNS round-robin load balancing.
Simple. No extra infrastructure.
But dumb - doesn't know if a server is down.
Geographic routing
User in India → IP of server in Mumbai.
User in US → IP of server in Virginia.
Closer server = lower latency.
This is how Cloudflare and AWS Route 53 work.
Failover
Primary server goes down.
DNS automatically points to backup.
Health checks run constantly.
Primary fails → DNS switches to backup.
This is DNS failover.
Service discovery
Internal microservices find each other via DNS.
payment-service.internal → 10.0.1.45
user-service.internal → 10.0.1.67
Kubernetes uses DNS internally for this.
We'll go deep on this in Phase 5.
DNS Security
DNS has problems.
DNS Spoofing
DNS has no built-in verification.
Resolver receives an answer.
No way to check if it's real.
Whoever answers fastest wins.
Attacker injects fake records:
google.com → attacker's IP
Everyone using that resolver goes to the attacker's server.
DNSSEC fixes this.
Every record is digitally signed.
Resolver verifies the signature.
Fake records rejected mathematically.
DNS over HTTPS (DoH)
Normal DNS queries are unencrypted.
Your ISP can see every domain you visit.
Even if the connection itself is HTTPS.
DoH encrypts the DNS query:
Normal DNS → plain text UDP → ISP sees everything
DoH → encrypted HTTPS → ISP sees nothing
Cloudflare's 1.1.1.1 supports DoH.
Mental Model
DNS → translates domain names to IP addresses
Hierarchy → Root → TLD → Authoritative nameserver
Resolver → the librarian that does the lookup
A record → domain to IPv4
AAAA record → domain to IPv6
CNAME → domain to another domain (alias)
MX → where to send email
TTL → how long to cache the answer
Propagation → time for new DNS to spread everywhere
UDP → DNS uses UDP (small query, small answer)
Round-robin → multiple IPs = simple load balancing
Failover → switch IP when server goes down
DNSSEC → digital signatures for DNS records
DoH → DNS queries encrypted over HTTPS
.co.in → second level domain under .in TLD
What Changed for Me
Before this:
DNS was just something that happened automatically.
After this:
I realized DNS is a distributed database
serving billions of queries per day,
cached at every level,
used for load balancing, failover, service discovery
and the reason you can type a name
instead of memorizing numbers.
What's Coming Next
IP addresses, ports and subnets.
How the internet routes packets
from your laptop in Kerala
to a server on the other side of the world.