Stop treating DNS like magic.
As an engineer I have been mostly heavy on the application development side. The usual stuff deciding the best framework to choose, how to optimise specific process, business domain implementation etc etc.
Hence my networking chops have never been very strong, as many other I definitely take many of such magnificent infrastructure as granted.
So when I planned to study and read about DNS, I though why not write my learnings about it. At least they would be documented.
So here we go
DNS Isn't really a simple Phonebook analogy. It's the Internet's Routing Nervous System
Lets say you are here at utsab.space , you type this address in the browser and hit enter, and within ~50-200ms you are directed to this blog.
What really happened?
If you are applcation developer and you are required to study databases then a way to look at it is - it’s a coordinated lookup across a globally distributed, hierarchical database that deliberately trades strict consistency for availability and latency. DNS isn’t a directory. It’s a cache-driven routing layer.
First Principles: Why DNS Exists at all?
Internet is a web of host (for the right reason we call it web) anyway, every host has IP (its address) so for every piece of content we are required to reach the correct address. But IPs are numeric, and for humans its an inconvenience to remember numbers for every website they want to visit in the internet.
/etc/hosts file worked for a few thousand machines. The ARPANET broke past ~1,000 hosts in the early ’80s. Coordination overhead exploded.DNS solved this with three architectural decisions:
- Hierarchical namespace: A tree rooted at
.(the empty label). Delegation flows downward: Root → TLD → Domain → Subdomain. - Decentralised authority: No single server holds the truth. Each zone owns its slice and delegates the rest via
NSrecords. - Cache-first, UDP-optimized: Queries are lightweight, stateless, and designed to terminate as close to the client as possible. Consistency is eventual. TTLs are suggestions, not contracts.
Lets Learn by actually tracing the request journey from your Browser to this Blog's host server
Let's make this concrete. We'll use utsabc.space as our case study and walk through the entire DNS resolution chain using standard CLI tools.
bind9-dnsutils (Linux), dnsutils (macOS via Homebrew), or use WSL on Windows. All commands below work on macOS/Linux.Step 0: Quick Sanity Check - What's the IP?
❯ dig +short utsabc.space
144.24.126.217
❯ dig +short www.utsabc.space
utsabc.space.
144.24.126.217Both resolve to the same Oracle Cloud IP in the Mumbai region (ap-mumbai-1).
Note: +short suppresses headers. For debugging, always start with full output:$ dig +trace utsabc.spaceBut many ISP networks block direct queries to root servers. So instead of relying on a black-box command, we trace it step by step.
Follow the Resolution Chain Manually (Iterative Mode)
Most engineers only see the final answer. Let's use dig like a recursive resolver and show us each hop.
Step 1 — Discover the Root Servers
Start by asking:
❯ dig . NS
; <<>> DiG 9.10.6 <<>> . NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60922
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 83885 IN NS d.root-servers.net.
. 83885 IN NS e.root-servers.net.
. 83885 IN NS f.root-servers.net.
. 83885 IN NS g.root-servers.net.
. 83885 IN NS h.root-servers.net.
. 83885 IN NS i.root-servers.net.
. 83885 IN NS j.root-servers.net.
. 83885 IN NS k.root-servers.net.
. 83885 IN NS l.root-servers.net.
. 83885 IN NS m.root-servers.net.
. 83885 IN NS a.root-servers.net.
. 83885 IN NS b.root-servers.net.
. 83885 IN NS c.root-servers.net.
;; Query time: 10 msec
;; SERVER: 2405:201:8020:b085::c0a8:1d01#53(2405:201:8020:b085::c0a8:1d01)
;; WHEN: Mon Apr 13 20:10:10 IST 2026
;; MSG SIZE rcvd: 239These are the root DNS servers — the starting point of all DNS resolution.
Step 2 — Resolve a Root Server IP
Pick one (say a.root-servers.net) and resolve it:
❯ dig a.root-servers.net
; <<>> DiG 9.10.6 <<>> a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30885
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;a.root-servers.net. IN A
;; ANSWER SECTION:
a.root-servers.net. 53621 IN A 198.41.0.4
;; Query time: 8 msec
;; SERVER: 2405:201:8020:b085::c0a8:1d01#53(2405:201:8020:b085::c0a8:1d01)
;; WHEN: Mon Apr 13 20:13:04 IST 2026
;; MSG SIZE rcvd: 63198.41.0.4Now we have a root server we can directly query.
Step 3 — Ask the Root Server
❯ dig @198.41.0.4 utsabc.space NS
; <<>> DiG 9.10.6 <<>> @198.41.0.4 utsabc.space NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15970
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;utsabc.space. IN NS
;; AUTHORITY SECTION:
space. 172800 IN NS ns10.trs-dns.info.
space. 172800 IN NS ns01.trs-dns.net.
space. 172800 IN NS ns10.trs-dns.org.
space. 172800 IN NS ns01.trs-dns.com.
;; ADDITIONAL SECTION:
ns10.trs-dns.info. 172800 IN A 64.78.204.1
ns10.trs-dns.info. 172800 IN AAAA 2620:171:812:1534:8::1
ns01.trs-dns.net. 172800 IN A 64.96.2.1
ns01.trs-dns.net. 172800 IN AAAA 2620:57:4002::1
ns10.trs-dns.org. 172800 IN A 64.78.205.1
ns10.trs-dns.org. 172800 IN AAAA 2620:171:813:1534:8::1
ns01.trs-dns.com. 172800 IN A 64.96.1.1
ns01.trs-dns.com. 172800 IN AAAA 2620:57:4001::1
;; Query time: 167 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Apr 13 20:14:12 IST 2026
;; MSG SIZE rcvd: 338This is where things get interesting. We are directly asking a root server:
“Who knows about utsabc.space?”It does not resolve the domain. Instead, it replies:
“I don’t know the domain, but I know who handles .space”Breaking down the response
Header
status: NOERROR
ANSWER: 0
AUTHORITY: 4NOERROR→ Query was validANSWER: 0→ No direct answer (expected!)AUTHORITY: 4→ It’s giving referrals
This is called a referral response
Important Line
WARNING: recursion requested but not availableRoot servers:
- do not perform recursion
- only provide direction
They are not resolvers — they are guides
Authority Section (The Key Part)
space. IN NS ns10.trs-dns.info.
space. IN NS ns01.trs-dns.net.
...This is the root server saying:
“If you want anything under .space, go talk to these servers”These are the TLD name servers for .space.
Key Insight
This step shows the core design of DNS:
- No single server knows everything
- Each layer only knows the next hop
That’s why DNS is scalable, distributed and fault-tolerant
This is the first real “handoff” in DNS resolution — from the root of the internet to the .space registry.
Step 4 — Ask the .space TLD
From the previous response, pick one of the TLD name servers:
This asks:
“Who is authoritative for this domain?”
The response gives the authoritative name servers.
❯ dig @ns10.trs-dns.org. utsabc.space NS
; <<>> DiG 9.10.6 <<>> @ns10.trs-dns.org. utsabc.space NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52795
;; 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
;; QUESTION SECTION:
;utsabc.space. IN NS
;; AUTHORITY SECTION:
utsabc.space. 900 IN NS dns1.registrar-servers.com.
utsabc.space. 900 IN NS dns2.registrar-servers.com.
;; Query time: 38 msec
;; SERVER: 2620:171:813:1534:8::1#53(2620:171:813:1534:8::1)
;; WHEN: Mon Apr 13 20:23:48 IST 2026
;; MSG SIZE rcvd: 100Step 5 — Ask the Authoritative Server
Now query the actual source of truth:
❯ dig @dns2.registrar-servers.com. utsabc.space A
; <<>> DiG 9.10.6 <<>> @dns2.registrar-servers.com. utsabc.space A
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60374
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;utsabc.space. IN A
;; ANSWER SECTION:
utsabc.space. 1799 IN A 144.24.126.217
;; AUTHORITY SECTION:
utsabc.space. 1800 IN NS dns1.registrar-servers.com.
utsabc.space. 1800 IN NS dns2.registrar-servers.com.
;; Query time: 38 msec
;; SERVER: 2610:a1:1025::200#53(2610:a1:1025::200)
;; WHEN: Mon Apr 13 20:26:08 IST 2026
;; MSG SIZE rcvd: 116And finally we have the ANSWER SECTION
144.24.126.217Final Flow
Root → .space TLD → Authoritative NS → A recordPart 2: Advanced DNS Architecture — Caching, Security, and the Control Plane
We traced the iterative resolution chain.We understood the delegation, glue records, and record types. Now let's go deeper.
DNS isn't just a lookup protocol. It's a distributed control plane for the internet. Its architecture decisions—cache-first, UDP-optimized, eventually consistent—ripple through every layer of modern infrastructure: CDNs, service meshes, zero-trust networks, and even Kubernetes.
In this section, we'll dissect the advanced concepts that separate "DNS works" from "DNS is engineered."
Caching Architecture: The Real Source of Truth
Core principle: The recursive resolver's cache is the operational source of truth for end users—not the authoritative server.
The Cache Hierarchy
When you look up utsabc.space, the answer doesn't come straight from the source every time. It gets cached (saved temporarily) at multiple levels:
- Your browser
- Your operating system
- Your ISP's resolver (or Cloudflare/Google)
Imagine DNS records are library books:
- Authoritative server = The publisher's warehouse (source of truth)
- Recursive resolver = Your local library branch (keeps popular books on shelf)
- TTL = Loan period (how long the branch keeps the book before checking if there's a new edition)
- Your browser = You, with a book checked out at home
If the publisher updates the book today:
- You won't see it until your copy expires (browser cache)
- Your library won't reorder until their loan period ends (resolver cache)
- Only then does someone fetch the new edition from the warehouse
See It in Action
# Check the TTL for utsabc.space's A record
❯ dig +noall +answer utsabc.space
utsabc.space. 1799 IN A 144.24.126.217
↑
This number = seconds the record can be cached
1800 seconds = 30 minutes
# Watch the TTL "count down" in a resolver's cache
❯ dig @1.1.1.1 +noall +answer utsabc.space
utsabc.space. 1799 IN A 144.24.126.217
❯ sleep 10
❯ dig @1.1.1.1 +noall +answer utsabc.space
utsabc.space. 1768 IN A 144.24.126.217Production Reality: Negative Caching
What if a domain doesn't exist? That answer gets cached too.
# Query a non-existent subdomain
# How long will resolvers cache "this doesn't exist"?
# Check the SOA record's last number (the "minimum" field):
❯ dig utsabc.space SOA +short
dns1.registrar-servers.com. hostmaster.registrar-servers.com. 1774956667 43200 3600 604800 3601
↑
Negative cache TTL = 3601 seconds (~1 hour)Rule of thumb: When deleting a subdomain, expect ~1 hour of "not found" responses globally. Plan accordingly.
EDNS0: When DNS Answers Get Too Big for UDP
DNS originally used UDP, a fast, connectionless protocol. But UDP has a size limit: 512 bytes for DNS responses.Modern features (DNSSEC signatures, long TXT records, extra metadata) can exceed that.EDNS0 (Extension Mechanisms for DNS) is a way to say: "Hey, I can handle bigger UDP packets — up to 4096 bytes if needed."If the answer is still too big? The server sets a "truncated" flag, and the client retries over TCP (slower, but reliable).
Analogy: Mailing a Package
- Original DNS = Sending a letter via standard envelope (512-byte limit)
- EDNS0 = Saying "I accept padded envelopes up to 4096 bytes"
- TC flag + TCP fallback = If it still won't fit, switch to courier service (TCP)
Lets See It in Action
# Ask for a large response and watch EDNS0 negotiate size
❯ dig +bufsize=1232 utsabc.space
; <<>> DiG 9.10.6 <<>> +bufsize=1232 utsabc.space
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23626
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280 <---- Client says: "I can accept UDP responses up to 1232 bytes"
;; QUESTION SECTION:
;utsabc.space. IN A
;; ANSWER SECTION:
utsabc.space. 1390 IN A 144.24.126.217
;; Query time: 10 msec
;; SERVER: 2405:201:8020:b085::c0a8:1d01#53(2405:201:8020:b085::c0a8:1d01)
;; WHEN: Mon Apr 13 21:17:19 IST 2026
;; MSG SIZE rcvd: 57
Why This Matters
- Some firewalls block DNS-over-TCP (port 53 TCP). If UDP responses get truncated and TCP is blocked, resolution fails silently.
- IPv6 networks often have smaller MTU (Maximum Transmission Unit). Using
bufsize=1232(instead of 4096) avoids fragmentation issues.
Best practice: Configure resolvers to use bufsize=1232 for IPv6 compatibility, and always allow TCP/53 fallback.
DNSSEC: Proving the Answer Is Authentic (Not Encrypted)
DNSSEC (DNS Security Extensions) adds digital signatures to DNS records. It lets you verify:
- This answer really came from the authoritative server
- The record wasn't altered in transit
DNSSEC does not encrypt your queries. Anyone can still see you looked up utsabc.space. It only prevents tampering.Analogy: Sealed, Signed Documents
Imagine DNS records are official documents:
- Without DNSSEC: Anyone can forge a document and slip it to you
- With DNSSEC: Each document has a cryptographic seal (signature). You can verify the seal using a public key published by the issuer.
The trust flows upward
Why Most Sites Don't Use DNSSEC
- Complex setup: Generating keys, signing zones, syncing DS records with your registrar
- Breakage risk: If the DS record at your registrar doesn't match your zone's key, validating resolvers will return
SERVFAIL(looks like "site down") - Limited threat coverage: Doesn't stop phishing, DDoS, or app-layer attacks
Enable DNSSEC if: You run a high-value domain (bank, government, critical infra) or compliance requires it.
GeoDNS & Anycast: Why You Get the "Closest" Server
When you query utsabc.space, you get 144.24.126.217 — an Oracle Cloud server in Mumbai.But someone in Frankfurt might get a different IP for the same name. How?Two techniques work together:
- Anycast: Multiple servers share the same IP address. BGP routing sends you to the nearest one.
- GeoDNS: The authoritative server looks at where your query came from and returns a location-appropriate answer.
Analogy: Emergency Services
- Anycast = Dialing "911" anywhere in the country → you reach the nearest dispatch center (same number, different physical location)
- GeoDNS = The dispatcher seeing your location and sending the closest ambulance
Hoping to have learnt something along the way
Its really interesting over the years we as humans did find really simple but ingenuous ways to solve such problems. The Rabbit hole of this infrastructure is definitely quite deep, and does intermingle with other networking concepts.
To continue this journey I am linking some reference materials for further reading/watching, and with your favourite AI you can always generate learning and exploration resources.
See author profile
Lorenzo Colitti Erik Romijn Henk Uijterwaal Andrei Robachevsky