DNS (Domain Name System) internet की टेलीफ़ोन डायरेक्टरी है: यह example.com जैसे मानव-पठनीय नाम को 93.184.216.34 जैसे IP address में अनुवादित करता है। Resolution एक पदानुक्रमित lookup है, जो आमतौर पर आपके लिए एक recursive resolver (आपके ISP का या 8.8.8.8 जैसा कोई सार्वजनिक) करता है जो आपकी ओर से authoritative name servers के पेड़ पर चलता है:
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 servers से पूछता है (जो TLD servers को जानते हैं), फिर .com के लिए TLD servers से (जो जानते हैं कि example.com के लिए कौन authoritative है), फिर authoritative server से (जो असली record रखता है)। इसे हर बार दोहराने से बचने के लिए, परिणाम हर स्तर पर cache किए जाते हैं — browser, OS, और resolver — हर एक record के TTL (time-to-live) का सम्मान करते हुए। एक गर्म cache माइक्रोसेकंड में resolve करता है; एक ठंडा lookup कई round trips ले सकता है।
आम record types: A (name → IPv4), AAAA (name → IPv6), CNAME (किसी अन्य नाम का उपनाम), MX (mail servers), TXT (मनमाना text, SPF/verification के लिए उपयोग), और NS (एक zone सौंपता है)। आप resolution को सीधे जाँच सकते हैं:
dig example.com A # A record और किस server ने उत्तर दिया दिखाता है
DNS हर उस request के महत्वपूर्ण रास्ते पर बैठता है जो एक नाम से शुरू होती है, इसलिए एक धीमा या ग़लत-configured resolver हर चीज़ में latency जोड़ता है। interviewers को यह सवाल पसंद है क्योंकि यह उजागर करता है कि क्या आप पदानुक्रम और caching को समझते हैं — वे दो विचार जो एक वैश्विक, वितरित सिस्टम को अरबों queries का तेज़ी से जवाब देने देते हैं। यह असली production घटनाओं का लगातार स्रोत भी है ("हमेशा DNS ही होता है"): समाप्त records, ग़लत TTLs, या किसी बदलाव के बाद propagation में देरी, इसलिए यह जानना कि caching और TTL कैसे काम करते हैं, सीधे व्यावहारिक है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें