DNS Deep Dive

DNS is the internet’s phonebook — and the single most common source of “it works on my machine / it’s broken / wait now it’s fixed” confusion. Master DNS and you can debug half of all infrastructure problems.

⏱ ~18 min · 🟡 Intermediate · Prerequisites: Lectures 1–2

🎯 What you’ll be able to do

Trace a DNS lookup through all four server types
Read and write every common record type (A, AAAA, CNAME, MX, TXT, NS)
Explain TTL and why changes seem to “take time to propagate”
Debug a DNS problem with dig / nslookup

The mental model

You know a person’s name but not their phone number, so you check a phonebook. Your computer knows ayrisglobal.com but needs 104.21.45.12, so it asks DNS. The clever part: there’s no single phonebook — it’s a distributed hierarchy, cached at every level for speed.

A lookup, step by step

When you request ayrisglobal.com, four kinds of servers cooperate:

Your computer
   │ "what's the IP of ayrisglobal.com?"
   ▼
[1] Recursive Resolver   (your ISP / 1.1.1.1 — does the legwork, caches answers)
   │   doesn't know? asks up the chain ↓
   ▼
[2] Root nameserver      ("ask the .com people → here they are")
   │
   ▼
[3] TLD nameserver (.com) ("ask ayrisglobal's nameservers → here they are")
   │
   ▼
[4] Authoritative NS     (Cloudflare — the source of truth: "it's 104.21.45.12")
   │
   ▼
Answer cached + returned ─► your browser connects

Server	Role	Analogy
Recursive resolver	Does the searching for you, caches results	A librarian who finds the book for you
Root	Points to the right TLD servers	”Phonebooks are over there”
TLD (`.com`, `.in`)	Points to the domain’s authoritative servers	The `.com` phonebook
Authoritative	Holds the real records — the source of truth	The actual phone number

Watch the chain run — first time it walks the full hierarchy (cold), then the resolver’s cache short-circuits it (warm):

Where your records live

The authoritative nameserver is whoever your domain’s NS records point to. For ayrisglobal.com that’s Cloudflare (lucy/elliott.ns.cloudflare.com). So you edit DNS in Cloudflare’s dashboard — that’s the source of truth the whole world eventually reads.

The record types you must know

A DNS zone is the set of records for a domain. Each record maps a name to a value.

Record	Maps…	Example value	Use it for
A	name → IPv4	`104.21.45.12`	Point a domain at a server
AAAA	name → IPv6	`2606:4700::6815`	Same, for IPv6
CNAME	name → another name	`myapp.vercel.app`	Alias one host to another
MX	domain → mail server	`mx1.zoho.com` (priority 10)	Where email is delivered
TXT	name → free text	`v=spf1 include:...`	Verification, SPF/DKIM/DMARC
NS	domain → its authoritative servers	`lucy.ns.cloudflare.com`	Delegate who runs the DNS
SOA	—	(admin metadata)	One per zone; you rarely touch it

A vs CNAME — the rule people get wrong

A points at an IP. CNAME points at another name. You cannot put a CNAME on the root/apex (ayrisglobal.com) in classic DNS — only on subdomains (www., app.). Modern providers like Cloudflare fake it with “CNAME flattening”, but the rule explains a lot of “why won’t this record save?” errors.

MX records — email’s address (preview of lecture 5)

MX = “Mail eXchange”. It tells senders which server accepts mail for a domain, with a priority (lower = tried first):

assure.ayrisglobal.com.   MX   5   mx1.hostinger.com.
assure.ayrisglobal.com.   MX  10   mx2.hostinger.com.

One MX set per domain

A domain has one set of MX records, so one inbound mail provider. You can’t have “some addresses at Hostinger, some at Zoho” on the same domain — whoever the MX points to handles all mail for it. (This single fact drives the whole email-migration decision in lecture 7.)

TTL & “propagation” — why changes feel slow

Every record has a TTL (Time To Live) in seconds — how long resolvers are allowed to cache the answer before re-asking.

TTL = 3600  →  resolvers cache for 1 hour
You change the record now
   → caches that fetched 10 min ago keep serving the OLD value for up to 50 more min

There’s no magic “propagation” process — it’s just caches expiring at different times around the world. The practical playbook:

Before any planned DNS change

Lower the TTL (e.g. to 300s = 5 min) a day before the change. Then when you flip the record, the world picks it up within ~5 minutes instead of hours. Raise it back afterwards for efficiency.

⚠️ Common misconceptions

Myth	Reality
”DNS changes take 24–48h.”	Usually minutes if TTL is low. The “48h” is a worst-case for high TTLs + slow resolvers.
”Propagation is something servers actively do.”	Nothing propagates. Old cached answers simply expire on their own schedules.
”I can CNAME my root domain.”	Not in classic DNS. Use A records, or a provider’s CNAME-flattening.
”More MX records = redundancy across providers.”	MX priority is failover within one provider. All MX should point to the same mail system.

🧪 Try it yourself

# The pro tool. Ask for a specific record type:
dig ayrisglobal.com A
dig assure.ayrisglobal.com MX
dig ayrisglobal.com TXT
dig ayrisglobal.com NS

# Windows (no dig): nslookup with -type
nslookup -type=mx assure.ayrisglobal.com
nslookup -type=ns ayrisglobal.com

# Ask a specific resolver (Cloudflare's 1.1.1.1) and see the TTL count down:
dig @1.1.1.1 ayrisglobal.com

Tip

Run dig twice in a row and watch the TTL number decrease — you’re literally watching a cache count down to expiry. That’s “propagation” demystified.

✅ Check yourself

Name the four server types in a DNS lookup and what each does.

Recursive resolver (does the legwork + caches), root (points to the right TLD), TLD server (points to the domain’s authoritative servers), authoritative nameserver (holds the real records — the source of truth).

When do you use an A record vs a CNAME?

A when you have an IP address to point at. CNAME when you want to alias to another hostname (e.g. point app.ayrisglobal.com at myapp.vercel.app). CNAME can’t sit on the root domain in classic DNS.

You changed a record but old values still show. Why, and what should you have done?

Resolvers cached the old value for its TTL. They’ll refresh when the TTL expires. To avoid the wait, you should have lowered the TTL (e.g. to 300s) a day before the change.

Can you split a domain's email across two providers using MX records?

No. A domain has one MX set, so one inbound mail handler. All MX records should point to the same mail system (priority is just failover within it). Splitting requires separate domains/subdomains.

What's the difference between the recursive resolver and the authoritative nameserver?

The recursive resolver (your ISP, or 1.1.1.1) does the legwork — it walks the hierarchy on your behalf and caches what it learns, but it owns no records. The authoritative nameserver (Cloudflare for ayrisglobal.com) actually holds the records and is the source of truth. One searches and caches; the other answers.

Which record type holds an SPF policy, and why is it that type?

A TXT record. SPF, DKIM, and DMARC are all just free-form text strings (v=spf1 include:...), and TXT is the record built for arbitrary text — so it’s also where domain-verification strings live.

Run `dig @1.1.1.1 ayrisglobal.com` twice and the TTL number drops. What are you watching?

A cache counting down to expiry. The resolver fetched the answer once and is now serving it from cache; the TTL shows how many seconds remain before it must re-ask the authoritative server. When it hits 0, the next query refetches and the TTL resets. That countdown is “propagation.”

📚 Resources

🟢 Cloudflare — What is DNS (whole DNS learning path): cloudflare.com/learning/dns/what-is-dns
🟢 Julia Evans — “How DNS works” comic + Mess With DNS (interactive!): messwithdns.net
🟡 DNS record types reference (Cloudflare): cloudflare.com/learning/dns/dns-records
🔴 dig deep dive / DNS for developers: jvns.ca/blog (search “dns”)

🧾 Key terms

Resolver · finds + caches answers · Authoritative NS · source of truth · Zone · a domain’s record set · A / AAAA · name→IP · CNAME · name→name · MX · mail destination · TXT · verification/policy text · NS · who’s authoritative · TTL · cache lifetime · Propagation · caches expiring, not a real process.

Still Unclear?

Paste any of these into Claude and make it work your example:

“I own a domain and want app.mydomain.com to serve a Vercel app while the root domain points at a Hostinger server. Walk me through the exact records (type, name, value) and tell me which one can’t be a CNAME and why.”
“Walk me through what dig +trace mydomain.com prints, line by line, and map each block to the root → TLD → authoritative chain.”
“I lowered my TTL to 300 yesterday and changed an A record an hour ago, but my friend still sees the old site. Give me the exact checks (which resolver, which cache) to find where the stale answer is coming from.”

Why AI Can’t Do This For You

AI can recite that “CNAME can’t sit on the apex” — but it can’t see your Cloudflare dashboard, your registrar’s NS delegation, or which of the dozen resolvers between you and a user is still serving the stale answer. DNS bugs are debugged by reasoning about a live, cached, distributed system in real time: reading a dig trace, knowing which TTL is biting, and deciding whether to wait or force a change. That judgment — built from having watched real records misbehave — is what makes you the person who fixes the outage while everyone else refreshes and prays.

One-line summary

DNS is a cached, distributed phonebook. Edit records at your authoritative provider (Cloudflare); records map names to values (A→IP, CNAME→name, MX→mail); “propagation” is just TTL caches expiring — lower the TTL before any change.

Module done? Add it to today’s tracker