DNS Resolution, Start to Finish

हर बार जब आप ब्राउज़र में कोई डोमेन टाइप करते हैं, तो एक श्रृंखला में lookups शुरू हो जाते हैं इससे पहले कि एक भी packet उस साइट तक पहुंचे जहां आप जाना चाहते हैं। उस श्रृंखला का अधिकांश हिस्सा अदृश्य है, और इसकी अधिकांश व्याख्याएं "यह एक फोन बुक की तरह है" पर रुक जाती हैं। यहां वास्तव में क्या होता है, चरण दर चरण, उन हिस्सों सहित जिन्हें लोग आमतौर पर छोड़ते हैं।

The stub resolver बुद्धिमान नहीं है

आपका operating system अपने आप से real DNS resolution नहीं करता। यह एक stub resolver चलाता है, कोड का एक पतला टुकड़ा जो केवल आपकी query को किसी भी DNS server के लिए आगे भेजता है जो /etc/resolv.conf में Linux पर या Windows पर आपके network adapter settings में configured है। इसे यहां check करें:

cat /etc/resolv.conf

वह फ़ाइल आमतौर पर आपके router (जैसे 192.168.1.1), आपके ISP के resolver, या एक public जैसे 1.1.1.1 या 8.8.8.8 की ओर इशारा करती है। The stub resolver के पास systemd-resolved जैसे local daemon द्वारा दिए गए OS या के अलावा अपना कोई cache logic नहीं है।

The recursive resolver असली काम करता है

जब आपकी query एक recursive resolver को हिट करती है, तो वह server उत्तर खोजने का काम संभाल लेता है, भले ही उसे वहां पहुंचने के लिए कई अन्य servers से पूछना पड़े। यदि उत्तर पहले से किसी पिछली lookup से cache में है, तो आपको यह तुरंत वापस मिल जाता है। TTL check करें:

dig example.com

ANSWER SECTION देखें — record type से पहले संख्या (जैसे A से पहले 300) TTL को सेकंड में दर्शाती है। यह है कि resolvers को record को फिर से पूछने से पहले कितने समय के लिए cache में रखने की अनुमति है।

यदि कुछ भी cache नहीं है, तो recursive resolver DNS पदानुक्रम के नीचे एक walk शुरू करता है।

Root, TLD, और authoritative servers

there are 13 root server addresses (a.root-servers.net से m.root-servers.net तक), प्रत्येक anycast routing के माध्यम से कई physical machines द्वारा समर्थित है। Root server नहीं जानता कि example.com कहां है, लेकिन वह जानता है कि कौन से servers .com को handle करते हैं, इसलिए वह एक referral वापस कर देता है।

Resolver फिर एक .com TLD server से पूछता है, जो फिर से अंतिम उत्तर नहीं जानता है लेकिन जानता है कि कौन से nameservers specifically example.com के लिए authoritative हैं। आप इस delegation को स्वयं देख सकते हैं:

dig +trace example.com

वह command हर hop दिखाता है: root, फिर TLD, फिर domain के लिए authoritative nameservers, actual A या AAAA record के साथ समाप्त। यह DNS को theoretically की जगह visually समझने के लिए सबसे अच्छा command है।

Authoritative nameserver अंतिम पड़ाव है। यह वह server है जिसे domain owner ने वास्तव में configure किया है, अक्सर registrar के DNS panel या Route 53 या Cloudflare DNS जैसी service के माध्यम से। यह पूरी श्रृंखला में एकमात्र server है जिसके पास cached copy या referral की जगह real, canonical answer है।

Record types जिनका आपको सामना करना पड़ेगा

एक A record एक नाम को IPv4 address के साथ map करता है, AAAA IPv6 के लिए भी ऐसा ही करता है। CNAME एक नाम को किसी IP की जगह दूसरे नाम की ओर इशारा करता है, जो है कि कैसे Cloudflare या Fastly जैसे CDNs raw IPs को expose किए बिना traffic route करते हैं। MX records mail routing को handle करते हैं, और TXT records arbitrary text carry करते हैं, सबसे commonly अब SPF, DKIM, और domain verification strings के लिए उपयोग किया जाता है। NS records दुनिया को बताते हैं कि कौन से servers एक zone के लिए authoritative हैं, और यह record type है जो पहली जगह में delegation को possible बनाता है।

जहां caching वास्तव में रहता है

Caching एक ही समय में multiple layers में होता है: ब्राउज़र स्वयं (Chrome के पास अपना DNS cache है जो chrome://net-internals/#dns पर viewable है), OS resolver cache, local router, और upstream recursive resolver। यह है कि कैसे एक DNS change एक device पर instantly काम करते हुए दिखाई दे सकता है और दूसरे पर घंटों दिखाई देने में लगते हैं — आप एक ही cache को hit नहीं कर रहे हैं।

जब आप एक planned migration से पहले record का TTL कम करते हैं, तो आप तुरंत कुछ भी तेज़ नहीं कर रहे हैं। आप केवल उस window को shrink कर रहे हैं जिसके दौरान stale data persist हो सकता है एक बार change वास्तव में होने के बाद। यह cutover से पांच मिनट पहले नहीं, बल्कि कम से कम एक TTL cycle in advance करें।

यह troubleshooting के लिए क्यों मायने रखता है

जब एक site unreachable है, dig +trace आपको बिल्कुल बताता है कि कौन सी layer broken है: एक root/TLD problem एक misconfigured authoritative server या आपकी अपनी machine पर stale cache की जगह बिल्कुल अलग दिखता है। dig example.com को एक known-good resolver के विरुद्ध compare करना, जैसे dig example.com @1.1.1.1, यह isolate करता है कि problem आपके local resolver में है या domain के actual DNS setup में।

DNS बाहर से सरल दिखता है क्योंकि यह आमतौर पर 100ms में resolve हो जाता है और कोई इसके बारे में नहीं सोचता। अंदर, यह एक distributed, cached, hierarchical query system है जो 1980s के बाद से अपने structure में लगभग unchanged चल रहा है, जो है कि कितना अच्छी तरह original design ने बनाए रखा इसका एक अच्छा argument।

अगर आप इसे आगे ले जाना चाहते हैं, Korra Studio के पास DEFENSE_GRID पर संबंधित segments हैं जो DNS security extensions, DNS tunneling as an exfiltration technique, और Python में अपना खुद का resolver building को cover करते हैं।