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

Principle mein True hai lekin woh alag roles play karte hain: recursive resolver clients ke liye referrals chase karta hai, authoritative server ek zone ke records store karta hai. Inhe mix karna discouraged hai kyunki ek recursive-open authoritative server ko cache-poisoning aur amplification attacks ke liye abuse kiya ja sakta hai.

False. 13 root server identities hain (letters a–m, purane UDP packet-size constraints se limited), lekin har ek anycast ke zariye worldwide hundreds of physical instances par replicated hai — Anycast Routing dekho. Toh 13 se kaafi zyada boxes hain.

False. TLD server sirf NS records jaanta hai — kaunsa authoritative server example.com handle karta hai. Actual A record us authoritative server par hota hai, TLD par nahi.

False. RFC (DNS/email rulebooks) ke anusaar, agar koi MX record exist nahi karta toh sender domain ke A/AAAA record par fallback karta hai ("implicit MX"). Delivery abhi bhi host tak attempt ki jaati hai — SMTP and Email Delivery dekho.

True aur common hai. A IPv4 address deta hai, AAAA IPv6 address deta hai (dekho IP Addressing — IPv4 vs IPv6); ek dual-stack host dono publish karta hai aur client apni connectivity ke hisaab se choose karta hai.

False. Ek CNAME doosre naam (ek canonical hostname) ki taraf point karta hai, kabhi IP ki taraf nahi. Resolver ko phir us naam ko resolve karna padta hai jab tak eventually ek A/AAAA record tak na pahunche.

False — yeh changes ko faster propagate karta hai lekin resolution ko average par slower banata hai, kyunki caches jaldi expire hote hain toh zyada queries miss hoti hain aur hierarchy mein dobara jaana padta hai. TTL freshness aur cache efficiency ke beech trade karta hai (dekho Caching and TTL).

Networking sense mein False. Ek recursive query ka matlab hai ki pucha gaya server final answer produce karne ki poori zimmedaari leta hai, jitna bhi legwork chahiye karta hai — yeh code recursion ke baare mein nahi, balki kaam ka maalik kaun hai iske baare mein hai.

Error: laptop ka stub resolver apne configured resolver ko ek recursive query bhejta hai aur wait karta hai. Root→TLD→authoritative ka iterative walk recursive resolver karta hai, tumhara laptop nahi.

Error: ek CNAME ko ek naam ki taraf point karna chahiye, IP ki taraf nahi. Yeh ftp.example.com. IN CNAME www.example.com. hona chahiye (jo phir A record resolve karta hai), ya agar directly IP chahiye toh ek A record.

Error: ek CNAME zone apex par nahi ho sakta kyunki yeh doosre records ke saath coexist nahi kar sakta, aur apex par mandatory SOA aur NS records already hote hain. Iske bajaye A/AAAA use karo (ya provider ka ALIAS/ANAME).

Error: lower number = higher preference (pehle try kiya jaata hai). Yahan 5 backup record 50 primary record se pehle try hoga, jo intent ke bilkul ulta hai. Numbers swap karo.

Error: root servers sirf TLD delegations jaante hain. example.com register karna .com TLD ke zone ko update karta hai, root ko nahi — root already jaanta hai .com kahan hai aur kisi naye site ke liye kabhi nahi badalta.

Aadha galat: TTL 0 ka matlab hai resolvers ko cache nahi karna chahiye, lekin change sirf unke liye "instant" hai jo ise honour karte hain — aur yeh tumhare authoritative server par har query ka pressure dalta hai. Kaafi resolvers minimum TTL bhi enforce karte hain, toh "har jagah instant" guaranteed nahi hai.

Error: CNAME chains legal hain (har hop ek doosre naam ki taraf point karta hai jab tak ek A/AAAA na mile). Performance ke liye (extra lookups) discouraged hain lekin forbidden nahi — resolvers chain follow karte hain.

Agar root servers recursively answer karte toh woh poori duniya ke har client ki taraf se full lookup karte aur instantly melt ho jaate. Iterative unhe sasta rakhta hai: woh sirf sahi TLD ka referral dete hain aur kuch nahi.

Ek akela HOSTS.TXT billions of hosts ke liye itni tezi se update, download, ya own nahi ho sakta tha. Namespace ko delegated tree mein todna matlab hai koi single machine sab kuch nahi jaanati — har level sirf agla jaanta hai, load aur authority spread hoti hai.

Popular answers clients ke paas unke TTL ke liye store rehte hain, toh zyaatar queries hierarchy mein gaye bina instantly serve hoti hain. Ek high cache-hit fraction ek multi-hop lookup ko common case ke liye near-zero kaam mein badal deta hai (dekho Caching and TTL).

Yeh ek canonical host deta hai jisi taraf kaafi aliases point karte hain. Canonical host ka IP ek baar change karo aur har alias automatically follow karta hai — har alias ka A record edit karne ki zaroorat nahi.

Number ek preference rank / "distance" hai, importance score nahi. Senders sabse-preferred (lowest) pehle try karte hain aur sirf higher numbers par jaate hain agar woh unreachable ho, ek deterministic failover order deta hua.

Kyunki delegation sabse significant part (root) se neeche flow hoti hai: root TLD ko delegate karta hai, TLD domain ke authoritative server ko. Right-to-left actually tree ke neeche resolution path ko mirror karta hai.

Kyunki woh source of truth hai — woh zone ke records store karta hai cache karne ki bajay. Uske answers "authoritative" mark hote hain aur bina kisi aur lookup ke trusted hote hain.

Kyunki RFC 2181 (DNS clarification standard) ise forbid karta hai: mail aur delegation logic target ko directly ek step mein address par resolve karna chahiye, aur ek CNAME extra indirection introduce karta jo kaafi servers reject ya mishandle karte hain.

Authoritative server ek NXDOMAIN (non-existent domain) response return karta hai. Yeh negative answer khud cacheable hai — SOA record ka timer set karta hai kitni der — toh baar baar galat lookups authoritative server ko hit karte nahi rehte.

Woh entry ko absent treat karta hai aur hierarchy se re-resolve karta hai, phir fresh result cache karta hai. Purani value discard ho jaati hai — TTL exactly yeh promise hai "mujhe sirf itni der trust karo."

Unhe nahi karna chahiye — secondaries zone transfers ke zariye primary se pull karte hain. Agar woh diverge hote hain (misconfiguration ya failed transfer), ek client inconsistent answers le sakta hai depending on kaunsa server usne poocha; jo bhi reply karta hai use authoritative treat kiya jaata hai.

Yeh root denote karta hai — yeh naam ek Fully Qualified Domain Name hai, relative ki bajay absolute. Dot ke bina, resolvers search domain append kar sakte hain (jaise www ko www.mycorp.local mein badal sakte hain).

DNS phir bhi AAAA record return karta hai — DNS tumhari connectivity nahi jaanta. Client ki connection logic (aksar Happy Eyeballs) IPv6 try karta hai, fail ya timeout hota hai, aur A record ke IPv4 par fallback karta hai. DNS ne apna kaam kiya; reachability ek alag layer hai.

Yeh RFC 2181 ke anusaar invalid hai — MX (aur NS) targets real hostnames hone chahiye jinke paas A/AAAA records hons, CNAME nahi. Kaafi mail servers ise reject ya mishandle karenge, toh hamesha MX ko ek aisi naam ki taraf point karo jo directly address resolve kare.

Tumhe ek NODATA response milega: naam exist karta hai lekin woh specific record type nahi karta. Yeh NXDOMAIN (naam bilkul exist nahi karta) se alag hai aur similarly ek negative answer ke roop mein cacheable hai.

Circular dependency: agar example.com ka NS ns1.example.com hai, toh tum ns1.example.com ka address nahi dhundh sakte bina pehle ye jaane ki example.com kahan serve hota hai. Glue records woh ns1.example.com A record hain jo parent (.com) TLD par NS delegation ke saath stored hain, loop todne ke liye taki resolver actually authoritative server tak pahunch sake.

Jab zone ke NS naam ek alag zone mein rehte hain (jaise example.com ns1.provider.net ko delegated hai). Phir ns1.provider.net independently .net ke zariye resolve hota hai, koi circular dependency nahi hoti, aur parent sirf NS record deta hai — koi glue nahi.

Yeh kisi bhi naam ke liye answer deta hai jiske paas koi zyada specific record nahi — jaise foo.example.com aur bar.example.com dono wildcard ke zariye resolve hote hain. Lekin explicitly defined naam (jaise www.example.com) precedence leta hai, aur wildcard deeper labels jaise a.b.example.com ko cover nahi karta jab tak woh bhi bina kisi closer match ke fall through na karein.

Haan us type ke liye jo woh cover karta hai: kyunki ek matching naam ab wildcard ke zariye "exist" karta hai, queries NXDOMAIN ki jagah data return karte hain. Lekin ek aisi type ki query ke liye jo wildcard provide nahi karta (jaise AAAA jab sirf ek wildcard A exist karta hai) NODATA milega, wildcard ka A nahi — wildcards naam-fallthrough par match karte hain, record types par nahi.

Technically allowed hai aur CDNs ke liye use hota hai (dekho CDN and Load Balancing), lekin usual CNAME rules abhi bhi laagu hote hain: wildcard sirf unhe match karta hai jinke paas koi zyada specific record nahi hai, aur yeh apex par help nahi kar sakta ya exact same wildcard naam par doosre data ke saath coexist nahi kar sakta.