DNS (Domain Name System) internet को फोन बुक हो: यसले example.com जस्तो मानिसले पढ्न मिल्ने नामलाई 93.184.216.34 जस्तो IP ठेगानामा अनुवाद गर्छ। Resolution एउटा पदानुक्रमिक lookup हो, प्रायः तपाईंका लागि एउटा recursive resolver (तपाईंको ISP को वा 8.8.8.8 जस्तो सार्वजनिक) ले गर्छ, जसले तपाईंको तर्फबाट authoritative name server हरूको रूख हिँड्छ:
Browser ──▶ Recursive Resolver ──▶ Root (.) "ask .com's servers"
│ ◀──
├────────▶ TLD (.com) "ask example.com's servers"
│ ◀──
└────────▶ Authoritative "example.com = 93.184.216.34"
(example.com) ◀──
Browser ◀── 93.184.216.34
Resolver ले root server हरू (जसले TLD server चिन्छन्) लाई सोध्छ, त्यसपछि .com का TLD server हरू (जसले example.com का लागि को authoritative हो थाहा पाउँछन्), त्यसपछि authoritative server (जसले वास्तविक record राख्छ)। हरेक पटक यो नदोहोर्याउन, नतिजा हरेक तहमा — browser, OS, र resolver — cache गरिन्छ, प्रत्येकले record को TTL (time-to-live) मान्दै। तातो cache ले microsecond मा resolve गर्छ; चिसो lookup ले धेरै round trip खर्च गर्न सक्छ।
सामान्य record type हरू: A (name → IPv4), AAAA (name → IPv6), CNAME (अर्को नामको alias), MX (mail server), TXT (मनपरी text, SPF/verification का लागि प्रयोग हुने), र NS (एउटा zone लाई delegate गर्छ)। तपाईं resolution सिधै जाँच्न सक्नुहुन्छ:
dig example.com A # shows the A record and which server answered
DNS नामबाट सुरु हुने हरेक request को critical path मा बस्छ, त्यसैले सुस्त वा गलत configure गरिएको resolver ले सबैमा latency थप्छ। Interviewer लाई यो प्रश्न मन पर्छ किनभने यसले तपाईं पदानुक्रम र caching बुझ्नुहुन्छ कि भनी उजागर गर्छ — यी दुई विचारले नै एउटा विश्वव्यापी, वितरित सिस्टमलाई अर्बौं query छिटो जवाफ दिन दिन्छन्। यो वास्तविक production घटनाको बारम्बार स्रोत पनि हो ("यो सधैं DNS हो"): म्याद सकिएका record, गलत TTL, वा परिवर्तनपछिको propagation ढिलाइ, त्यसैले caching र TTL कसरी काम गर्छ भन्ने थाहा पाउनु सिधै व्यावहारिक छ।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्