Worked examples — DNS — recursive vs iterative query, hierarchy, record types (A, AAAA, CNAME, MX, NS)

4.3.23 · D3 · Coding › Computer Networks › DNS — recursive vs iterative query, hierarchy, record types

The scenario matrix

Kuch bhi solve karne se pehle, chalte hain har distinct case class list karte hain jo yeh topic produce kar sakta hai. Niche har worked example us cell ke saath tagged hai jo woh fill karta hai.

Har row niche cover ki gayi hai. Chalte hain.

Example 1 — Full cache-miss (Cell C1)

Forecast: padhne se pehle hops ka guess lagao. Root? TLD? Authoritative? Total kitne round trips?

1. Laptop → resolver (recursive). Yeh step kyun? Tumhara laptop ek "stub" hai — woh sirf ek recursive question pooch sakta hai aur wait kar sakta hai. Yeh 1 round trip hai jo niche sab kuch wrap karta hai; yeh resolver ke internal iterative hop count mein add nahi hota.
2. Resolver → root (iterative). Yeh step kyun? Empty cache matlab resolver kuch nahi jaanta, toh woh top se start karta hai. Root reply karta hai ".com TLD se poochho." → 1 iterative hop.
3. Resolver → TLD .com (iterative). Yeh step kyun? Referral yahan point karta tha. TLD reply karta hai "ns1.example.com se poochho." → 2nd iterative hop.
4. Resolver → authoritative (iterative). Yeh step kyun? Authoritative server actually record store karta hai. Woh reply karta hai "A = 93.184.216.34." → 3rd iterative hop.
5. Time count karo. $H_{\text{iter}}=3$ resolver ke iterative hops hain (root, TLD, auth), aur 1 stub round trip add karo. Time $=3\times 30+30=120\text{ ms}$ (3 chase hops + 1 laptop hop).

Verify karo: figure mein arrows count karo — root, TLD, auth = 3 iterative arrows, plus recursive arrow laptop se/tak. $H_{\text{iter}}=3$, total time $=(3+1)\times 30=120\text{ ms}$. Units: ms per hop × hops = ms. ✓

Example 2 — Cache-hit, the best case (Cell C2)

Forecast: is baar root/TLD/auth mein se kitno ko contact karenge?

1. Laptop → resolver (recursive). Yeh step kyun? Same stub behaviour — ek recursive question. Yeh stub round trip kabhi nahi jaata: perfect cache bhi chahta hai ki tumhara laptop resolver se pooche aur jawab sune.
2. Resolver pehle cache check karta hai. Yeh step kyun? Caching ka pura point yahi hai: network touch karne se pehle, locally dekho. Entry www.example.com → 93.184.216.34 present hai aur TTL > 0 hai.
3. Resolver turant jawab deta hai. Yeh step kyun? Koi referral chasing zaroori nahi → 0 iterative hops. Latency = sirf ek laptop↔resolver round trip $=30\text{ ms}$.

Verify karo: iterative hops = 0 (teeno servers skip), lekin stub hop rehta hai. Latency = $30\text{ ms}$ vs $120\text{ ms}$ uncached — ek $4\times$ speedup, jo $H_{\text{iter}}+1=4$ round trips ke $1$ mein collapse hone se match karta hai. ✓ Dekho Caching and TTL.

Example 3 — Partial cache, the realistic middle (Cell C3)

Forecast: kaun se levels skip hote hain — root, TLD, dono?

1. Resolver cache check karta hai. Yeh step kyun? Cache sirf final answers nahi, referrals bhi store karta hai. Use milta hai ".com → gtld server" aur "example.com → ns1". Root aur TLD already pata hain.
2. Root aur TLD skip karo. Yeh step kyun? Kyunki woh referrals cached hain aur expire nahi hue, unhe dobara poochne ki koi zaroorat nahi. Yeh key insight hai: caching un names ke liye bhi help karta hai jo kabhi nahi dekhe, jab tak unke ancestors dekhe gaye hon.
3. Resolver → sirf authoritative (iterative). Yeh step kyun? Sirf leaf record blog.example.com missing hai. Ek hop use fetch karta hai. → 1 iterative hop.
4. Time $=1\times 30+30=60\text{ ms}$ (1 chase hop + 1 laptop hop).

Verify karo: iterative hops = 1 (vs 3 cold). Time $=(1+1)\times 30=60\text{ ms}$, jo neatly $120\text{ ms}$ cold case aur $30\text{ ms}$ hit case ke beech baitha hai. ✓

Example 4 — Alias resolution / CNAME chain (Cell C4)

Forecast: kya ek query IP return karti hai, ya CNAME doosra lookup force karta hai? Total kitna time?

1. Resolver → auth: "ftp.example.com ka A record?" Yeh step kyun? Client ek IPv4 address chahta hai, toh woh type A maangta hai. Kyunki authoritative NS already cached hai, yeh 1st iterative hop hai (root aur TLD skip hain).
2. Auth ek CNAME return karta hai, A nahi. Yeh step kyun? ftp ka koi A record nahi — yeh ek alias hai. Server jawab deta hai "ftp actually www.example.com hai," jo ek naam hai, woh number nahi jo client chahta tha.
3. Resolver dobara poochha: "www.example.com ka A record?" Yeh step kyun? IP abhi bhi haath mein nahi hai. Alias ko follow karna padega ek real A record tak pahunchne ke liye. Yeh 2nd iterative hop hai aur yeh 93.184.216.34 deta hai. (Well-behaved authoritative servers aksar target ka A usi reply mein bundle karte hain is hop ko bachane ke liye — lekin logically yeh doosra lookup hai, aur hum ise aisa hi count karte hain.)
4. Resolver 93.184.216.34 client ko return karta hai, aur time total karta hai. Yeh step kyun? Client sirf final IP care karta tha; CNAME indirection uske liye invisible hai. Hops count karo: 2 iterative (do authoritative queries) + 1 stub round trip $=(2+1)\times 30=90\text{ ms}$.

Verify karo: CNAME target www.example.com A = 93.184.216.34 resolve karta hai, toh ftp aur www same IP share karte hain. Hops = 2 iterative + 1 stub, latency $=(2+1)\times 30=90\text{ ms}$. www ka A record change karna automatically ftp ko bhi move kar dega — alias ka pura point yahi hai. ✓

Example 5 — MX priority: tie + fallback (Cell C5)

Forecast: pehle kaun sa server — aur 10 par tie ka matlab kya hai?

1. MX priority number ke hisaab se ascending order mein sort karo. Yeh step kyun? Chhota number = preferred (counter-intuitive lekin definition ke hisaab se — "rank #1" sochon). Toh priority 10 servers 20 se pehle aate hain. Dekho SMTP and Email Delivery.
2. Priority 10 par tie ko random/round-robin se break karo. Yeh step kyun? Do equal-priority MX records ka matlab hai load share karna; sender ya toh mail1 ya mail2 randomly pick karta hai. Yeh mail dono mein distribute karta hai.
3. backup (20) par tab hi fall back karo jab dono 10s fail ho jaayein. Yeh step kyun? Priority 20 last resort hai — ek lower-preference server sirf tab use hota hai jab har higher-preference wala unreachable ho.

Verify karo: ordering hai $\{\text{mail1},\text{mail2}\}$ (koi bhi order, priority 10) phir backup (priority 20). Minimum priority value $\min (10,10,20)=10\Rightarrow$ do mail hosts ke beech tie. Backup strictly last hai. ✓

Example 6 — A vs AAAA: both degenerate cases (Cell C6)

Forecast: kya IPv6 client hamesha IPv6 address paata hai? Kya IPv4-only client v6 tak pahunch sakta hai?

1. dual ke liye, IPv6-preferring client pehle AAAA poochha karta hai. Yeh step kyun? Modern clients IPv6 try karte hain jab available ho. AAAA returns 2001:db8::7 → IPv6 par connect. Agar woh fail hota, toh woh "Happy-Eyeballs" A record 198.51.100.7 par fall back karta.
2. old (no AAAA) ke liye, client AAAA poochha karta hai aur empty answer paata hai. Yeh step kyun? Yeh degenerate "no IPv6" case hai. Empty AAAA response koi error nahi hai; bas iska matlab hai "is type ka koi record nahi." Client A record 198.51.100.8 par fall back karta hai — yahan ek IPv6 client bhi IPv4 use karta hai.
3. v6 (only AAAA) ke liye, IPv6 client AAAA poochha karta hai aur succeed karta hai. Yeh step kyun? Yeh symmetric "only IPv6" case hai. AAAA 2001:db8::9 return karta hai aur koi A fall back karne ke liye nahi hai — na hi kisi ki zaroorat hai.
4. Legacy IPv4-only client v6 ke liye pooche toh kuch usable nahi milta. Yeh step kyun? Woh A query karta hai, empty answer paata hai, aur AAAA use karne ke liye koi IPv6 stack nahi hai. Woh v6 tak bilkul nahi pahunch sakta — yahi edge case public services ko dual-stack motivate karta hai.

Verify karo: dual → 2 address families (AAAA preferred, A backup). old → AAAA empty, A 198.51.100.8 use hota hai (1 family). v6 → AAAA 2001:db8::9, koi A nahi (1 family); ek IPv4-only client 0 usable addresses deta hai. ✓ Dekho IP Addressing — IPv4 vs IPv6.

Example 7 — Degenerate / illegal config (Cell C7)

Forecast: kaun si lines legally coexist nahi kar saktin, aur kyun?

1. Line 1 — apex CNAME illegal hai. Yeh step kyun? Zone apex example.com. mein SOA aur NS records hone zaroori hain. Ek CNAME kehta hai "main sirf ek alias hoon — mere saare doosre records ignore karo," jo required SOA/NS ke saath seedha contradict karta hai. Fix: apex par ek A/AAAA record (ya provider ka ALIAS/ANAME) use karo.
2. Line 2+3 — NS aur A same name par delegation clash hai. Yeh step kyun? www.example.com par ek NS record us subtree ko doosre server ko delegate karta hai — matlab "main www ke liye jawab nahi deta." Lekin line 3 locally A record ke saath www ke liye jawab dene ki koshish karti hai. Tum delegate karna aur khud jawab dena dono ek saath nahi kar sakte. Fix: NS drop karo agar www ek normal host hai (A rakho), ya local A drop karo agar tum sach mein delegate kar rahe ho.
3. General rule batao. Yeh step kyun? CNAME kisi bhi doosre record type ke saath coexist nahi kar sakta; NS-delegation aur same name ke locally-served records mutually exclusive hain. Dono broken lines "ek authority per name/type" violate karte hain.

Verify karo: apex CNAME mandatory apex SOA/NS se conflict karta hai ⇒ illegal (parent note ki mistake #3 se match karta hai). NS + A identical name par ⇒ ambiguous authority ⇒ illegal. Do problems found. ✓

Example 8 — Limiting behaviour of the cache cost model (Cell C8)

Forecast: kaun sa limit "internet melt ho jaata hai" hai aur kaun sa "instant" hai? Aur kya $p\to 1$ sach mein 0 ms deta hai?

1. Pehle samjho symbols ka kya matlab hai yahan. Yeh step kyun? Parent ka $H=4$ secretly stub hop include karta tha. Agar koi reader seedha is page par aaye, woh hidden convention algebra confuse kar degi. Toh is page par $H_{\text{iter}}=3$ purely chase hops hai aur stub $t$ akela khada hai — yahi reason hai hamare formula mein standalone $+t$ hai.
2. Limit $p\to 0$ (kuch cached nahi). Yeh step kyun? Worst case — har query full miss hai. Total $\to 30+(1-0)\cdot 3\cdot 30=30+90=120\text{ ms}$. Yeh cold-cache Ex 1 number hai: model ka upper bound.
3. Limit $p\to 1$ (sab cached). Yeh step kyun? Best case — chase term vanish ho jaata hai, lekin stub hop rehta hai. Total $\to 30+(1-1)\cdot 3\cdot 30=30+0=30\text{ ms}$. Yeh exactly Ex 2 se match karta hai — 0 ms nahi, kyunki tumhara laptop hamesha resolver se poochhega aur wait karega.
4. Realistic $p=0.9$. Yeh step kyun? Real resolvers ~90% hit karte hain. Total $=30+(1-0.9)\cdot 3\cdot 30=30+0.1\cdot 90=30+9=39\text{ ms}$ average. Chase portion $90$ ms se gir ke $9$ ms ho gaya — network work mein 10× cut — jabki fixed stub floor $30$ ms par rakhta hai. Yahi reason hai DNS scale karta hai: expensive tree-walking zyaadatar cache se serve hoti hai, sirf unavoidable stub round trip bacha rehta hai.

Verify karo: $p=0\Rightarrow 120$, $p=1\Rightarrow 30$ (floor = stub hop, Ex 2 se consistent), $p=0.9\Rightarrow 39$. Total $p$ mein linear hai slope $-H_{\text{iter}}t=-90$ ke saath, endpoints $120$ aur $30$. ✓

Example 9 — Real-world latency word problem (Cell C9)

Forecast: DNS wait ka bada ya chhota hissa hai?

1. DNS time = (3 chase + 1 stub) × 40. Yeh step kyun? Same hop accounting Ex 1 jaisi, bas $40\text{ ms}$ par: $(3+1)\times 40=160\text{ ms}$.
2. HTTP fetch add karo. Yeh step kyun? IP pata hone ke baad hi browser connection khol sakta hai aur page request kar sakta hai. Total $=160+200=360\text{ ms}$. Dekho HTTP and the Web request lifecycle.
3. DNS fraction. Yeh step kyun? Yeh judge karne ke liye ki caching/CDN worth it hai: $160/360\approx 0.444$, matlab cold cache par ~44% wait DNS hai.
4. Second visit par (cache hit), DNS stub floor $40$ ms tak gir jaata hai. Yeh step kyun? Yeh payoff dikhata hai aur Ex 8 ke floor se consistent hai: chase term disappear ho jaata hai lekin ek stub round trip rehti hai. Total ban jaata hai $40+200=240\text{ ms}$ — sirf caching se $120\text{ ms}$ ki bachat. Ek CDN/anycast resolver miss path aur shrink kar dega.

Verify karo: cold total $=160+200=360\text{ ms}$; DNS fraction $=160/360=0.4\overline{4}$; warm total $=40+200=240\text{ ms}$; saving $=360-240=120\text{ ms}$. ✓

Example 10 — Exam twist: TTL expiry timing (Cell C10)

Forecast: kya $t=200\text{ s}$ query nayi IP dekhta hai?

1. Cache $t=0+300=300\text{ s}$ tak valid hai. Yeh step kyun? TTL record ki lifetime in cache hai jis moment se store hua tha. Expire hone tak, resolver cached value serve karta hai dobara pooche bina.
2. $t=200\text{ s}$ par query → OLD IP. Yeh step kyun? $200<300$, toh entry abhi bhi fresh hai. Admin ka $t=120$ par change invisible hai — resolver ne dobara check nahi kiya. Yahi reason hai DNS changes "propagate hone mein time lete hain."
3. $t=300\text{ s}$ par entry expire ho jaati hai. Yeh step kyun? Ab agla query ek fresh authoritative lookup force karta hai.
4. $t=350\text{ s}$ par query → NEW IP. Yeh step kyun? $350>300$, cache expired, resolver authoritative se re-fetch karta hai → updated record dekhta hai. Dekho Caching and TTL.

Verify karo: expiry $t=300$ par. Query $200$ par: $200<300\Rightarrow$ old IP. Query $350$ par: $350>300\Rightarrow$ new IP. Change ke baad staleness window $300-120=180\text{ s}$ hai. ✓

Active Recall

Flashcards