DNS रिकॉर्ड्स को कैसे देखें
DNS वह सिस्टम है जो डोमेन नामों को IP पतों में अनुवाद करता है। जब कुछ गलत होता है, वेबसाइट लोड नहीं हो रही, ईमेल नहीं पहुंच रहा, या SSL प्रमाणपत्र विफल हो रहा, तब DNS रिकॉर्ड्स की जांच लगभग हमेशा डीबगिंग का पहला कदम होता है। प्रत्येक रिकॉर्ड प्रकार क्या करता है, क्वेरीज़ सिस्टम में कैसे प्रवाहित होती हैं, और जब परिणाम मेल नहीं खाते तो कहां देखना है, यह समझना रहस्यमय आउटेज को सुलझाने योग्य समस्याओं में बदल देता है।
DNS का संक्षिप्त इतिहास
DNS से पहले, प्रारंभिक इंटरनेट पर हर कंप्यूटर HOSTS.TXT नामक एक ही फ़ाइल साझा करता था, जिसे स्टैनफोर्ड रिसर्च इंस्टीट्यूट द्वारा बनाए रखा जाता था। प्रत्येक साइट अन्य मशीनों के IP पते जानने के लिए नियमित रूप से फ़ाइल डाउनलोड करती थी। जब नेटवर्क में कुछ सौ होस्ट थे तब सिस्टम काम करता था। यह स्केल नहीं हुआ।
1983 में, पॉल मॉकापेट्रिस ने RFC 882 और RFC 883 प्रकाशित किए, जिन्होंने एक पदानुक्रमित वितरित नामकरण प्रणाली का वर्णन किया: डोमेन नेम सिस्टम। 1987 में विशिष्टताओं को RFC 1034 (अवधारणाएं और सुविधाएं) और RFC 1035 (कार्यान्वयन और विनिर्देश) में परिष्कृत किया गया, जो आज भी मूलभूत दस्तावेज़ बने हुए हैं। एक विशाल फ़ाइल के बजाय, नेमस्पेस को ज़ोनों में विभाजित किया गया, प्रत्येक का अपना आधिकारिक सर्वर, और पेड़ के शीर्ष पर रूट सर्वरों का एक छोटा सेट।
तब से DNS का लगातार विस्तार हुआ है। AAAA रिकॉर्ड्स (RFC 3596, 2003) ने IPv6 समर्थन जोड़ा। DNSSEC (RFC 4033 से 4035, 2005) ने स्पूफिंग से बचाने के लिए क्रिप्टोग्राफिक हस्ताक्षर जोड़े। DNS-over-TLS (RFC 7858, 2016) और DNS-over-HTTPS (RFC 8484, 2018) ने क्वेरीज़ को एन्क्रिप्ट किया ताकि सुनने वाले और मिडिलबॉक्स उन्हें न देख सकें और न ही बदल सकें। सिस्टम की हर परत पीछे की संगतता बनाए रखती है, यही कारण है कि चालीस साल पुराना प्रोटोकॉल अब भी आधुनिक वेब चला रहा है।
DNS रिकॉर्ड प्रकार
दर्जनों DNS रिकॉर्ड प्रकार हैं, लेकिन मुट्ठी भर ही वास्तविक दुनिया की अधिकांश लुकअप को कवर करते हैं। प्रत्येक क्या करता है यह जानना ट्राइएज को तेज करता है।
| रिकॉर्ड | उद्देश्य | उदाहरण मान |
|---|---|---|
| A | डोमेन को IPv4 पते से मैप करता है | 93.184.216.34 |
| AAAA | डोमेन को IPv6 पते से मैप करता है | 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME | एक डोमेन को दूसरे का उपनाम बनाता है | www CNAME example.com |
| MX | डोमेन के लिए मेल सर्वर | 10 mail.example.com |
| TXT | मुक्त-रूप पाठ (SPF, DKIM, सत्यापन) | v=spf1 include:_spf.google.com ~all |
| NS | डोमेन के आधिकारिक नेम सर्वर | ns1.example.com |
| SOA | Start of Authority (ज़ोन मेटाडेटा) | प्राथमिक NS, व्यवस्थापक ईमेल, सीरियल, रिफ्रेश |
| SRV | सेवा स्थान (होस्ट और पोर्ट) | _sip._tcp.example.com 0 5 5060 sip.example.com |
| PTR | रिवर्स DNS (IP से नाम) | 34.216.184.93.in-addr.arpa PTR example.com |
| CAA | कौन से CA प्रमाणपत्र जारी कर सकते हैं | 0 issue "letsencrypt.org" |
| DNSKEY | DNSSEC सत्यापन के लिए उपयोग की जाने वाली सार्वजनिक कुंजी | (बाइनरी कुंजी डेटा) |
| NAPTR | ENUM और SIP के लिए regex-आधारित पुनर्लेखन | (जटिल flag/regex टपल) |
A, AAAA, CNAME और MX अधिकांश रोज़मर्रा के प्रश्नों का उत्तर देते हैं। TXT, NS, SOA और CAA कॉन्फ़िगरेशन और सुरक्षा ऑडिट के दौरान आते हैं। SRV और NAPTR VoIP, XMPP और अन्य सेवा-खोज प्रोटोकॉल के लिए मायने रखते हैं। PTR मेल सर्वरों के लिए मायने रखता है, क्योंकि अधिकांश स्पैम फ़िल्टर वैध रिवर्स DNS के बिना प्रेषकों को अस्वीकार करते हैं।
DNS रिकॉर्ड कैसे देखें
- एक डोमेन दर्ज करें: लुकअप टूल में कोई भी डोमेन नाम (उदाहरण के लिए, example.com) टाइप करें। यदि आप किसी विशेष लेबल के रिकॉर्ड चाहते हैं तो आप mail.example.com जैसे सबडोमेन भी दर्ज कर सकते हैं।
- रिकॉर्ड प्रकार चुनें: A, AAAA, MX, TXT, CNAME, NS, SOA या CAA चुनें। टूल त्वरित अवलोकन के लिए एक साथ सभी सामान्य प्रकारों की क्वेरी का भी समर्थन करता है।
- परिणामों की समीक्षा करें, प्रतिक्रिया प्रत्येक मिलान करने वाले रिकॉर्ड को उसके मान, TTL (कितनी देर तक रिज़ॉल्वर इसे कैश कर सकते हैं), और MX प्राथमिकता या SOA सीरियल नंबर जैसे किसी भी अतिरिक्त फ़ील्ड के साथ सूचीबद्ध करती है।
- अपेक्षाओं से तुलना करें: यदि आपने अभी एक रिकॉर्ड बदला है, तो जांचें कि नया मान दिखाई दे रहा है। यदि आप किसी तीसरे पक्ष को डीबग कर रहे हैं, तो जो आप देख रहे हैं उसकी तुलना उससे करें जो उन्होंने कहा था कि उन्होंने कॉन्फ़िगर किया है।
DNS से वास्तविक समस्याओं को डीबग करना
वेबसाइट लोड नहीं हो रही? A और AAAA रिकॉर्ड्स की जांच करें। यदि वे गायब हैं, तो डोमेन कनेक्ट नहीं है; यदि वे पुराने IP की ओर इशारा करते हैं, तो ट्रैफ़िक उस सर्वर पर पहुंच रहा है जो अब साइट होस्ट नहीं करता। यह भी पुष्टि करें कि NS रिकॉर्ड्स रजिस्ट्रार की सूचीबद्ध नेम सर्वरों से मेल खाते हैं, क्योंकि बेमेल का अर्थ है कि पूरा ज़ोन एक पुराने स्रोत से परोसा जा रहा है।
ईमेल नहीं आ रहा? पहले MX रिकॉर्ड्स की जांच करें; गायब या गलत MX रिकॉर्ड्स का अर्थ है कि कुछ भी डिलीवर नहीं हो सकता। फिर SPF (v=spf1), DKIM (default._domainkey या समान), और DMARC (_dmarc.example.com) के लिए TXT रिकॉर्ड्स की जांच करें। आधुनिक मेल प्रदाता इन जांचों में विफल होने वाले संदेशों को अस्वीकार या क्वारंटाइन करते हैं, इसलिए एक गायब रिकॉर्ड चुपचाप आपके संदेशों को स्पैम में भेज सकता है।
SSL प्रमाणपत्र त्रुटियां? जांचें कि A रिकॉर्ड उस सर्वर की ओर इशारा करता है जहां प्रमाणपत्र स्थापित है। यदि साइट CDN के पीछे है, तो A रिकॉर्ड को CDN एज पर रिज़ॉल्व होना चाहिए, मूल पर नहीं। CAA रिकॉर्ड्स भी जांचें; एक CAA जो केवल एक प्रमाणपत्र प्राधिकरण को सूचीबद्ध करता है, अन्य सभी को जारी करने से रोकेगा, भले ही डोमेन स्वामी उम्मीद करता हो कि वे काम करेंगे।
डोमेन सत्यापन विफल हो रहा? Google Workspace, Microsoft 365, Cloudflare और अधिकांश SaaS प्लेटफ़ॉर्म डोमेन स्वामित्व साबित करने के लिए TXT रिकॉर्ड जोड़ने को कहते हैं। यह पुष्टि करने के लिए TXT रिकॉर्ड्स देखें कि सटीक स्ट्रिंग मौजूद है, जिसमें प्लेटफ़ॉर्म द्वारा आवश्यक कोई भी उद्धरण या उपसर्ग शामिल है।
DNS प्रसार धीमा महसूस हो रहा? रिकॉर्ड बदलने के बाद, दुनिया भर के रिज़ॉल्वर TTL समाप्त होने तक कैश किए गए मान परोसते रहते हैं। नियोजित परिवर्तन से एक दिन पहले TTL को 300 सेकंड पर कम करना बदलाव को बहुत तेज़ बनाता है। लुकअप टूल प्रत्येक रिकॉर्ड के साथ वर्तमान TTL दिखाता है, ताकि आप अनुमान लगा सकें कि पुराने मान कितनी देर तक बने रहेंगे।
SPF, DKIM और DMARC
तीन TXT-आधारित रिकॉर्ड ईमेल को स्पूफिंग से बचाते हैं। SPF सूचीबद्ध करता है कि कौन से सर्वर आपके डोमेन के लिए मेल भेजने के लिए अधिकृत हैं। DKIM एक सार्वजनिक कुंजी प्रकाशित करता है जिसका उपयोग प्राप्तकर्ता प्रत्येक संदेश पर क्रिप्टोग्राफिक हस्ताक्षर सत्यापित करने के लिए करते हैं। DMARC प्राप्तकर्ताओं को बताता है कि जब SPF या DKIM विफल हो तो क्या करें: कुछ नहीं, क्वारंटाइन, या अस्वीकार। तीनों DNS में रहते हैं, तीनों हर इनबाउंड संदेश पर क्वेरी किए जाते हैं, और किसी में भी टाइपो डिलीवरी क्षमता को पंगु बना सकता है। DNS लुकअप टूल वास्तव में जो प्रकाशित है उसे पढ़ने का सबसे तेज़ तरीका है, उस से अलग जो कॉन्फ़िगरेशन इंटरफ़ेस दावा करता है।
प्रमाणपत्र प्रावधान और CAA
जब आप TLS प्रमाणपत्र का अनुरोध करते हैं, तो प्रमाणपत्र प्राधिकरण नियंत्रण सत्यापित करने के लिए DNS की क्वेरी करता है। अधिकांश dns-01 चुनौती का उपयोग करते हैं: वे आपसे _acme-challenge के तहत एक विशिष्ट TXT रिकॉर्ड प्रकाशित करने के लिए कहते हैं, फिर जांचते हैं कि यह दिखाई दिया। CAA रिकॉर्ड एक अतिरिक्त परत जोड़ते हैं; वे घोषित करते हैं कि कौन से प्राधिकरण डोमेन के लिए प्रमाणपत्र जारी कर सकते हैं। एक गलत कॉन्फ़िगर किया गया CAA वैध नवीनीकरण को अवरुद्ध कर सकता है, इसलिए जब भी Let's Encrypt क्रॉन अचानक काम करना बंद कर दे, CAA की जांच करें।
सामान्य नुकसान
- पुनरावर्ती को आधिकारिक उत्तरों से भ्रमित करना, आपके ISP का रिज़ॉल्वर एक कैश की गई प्रति परोस सकता है जो वास्तविकता से घंटों पीछे है। लुकअप टूल Cloudflare के DNS-over-HTTPS एंडपॉइंट का उपयोग करता है, जो आधिकारिक सर्वरों से सीधे क्वेरी करता है और ISP कैश को बायपास करता है।
- TTL को अनदेखा करना, यदि किसी रिकॉर्ड का TTL 86400 सेकंड (24 घंटे) है, तो परिवर्तन हर जगह दिखाई देने में पूरा दिन ले सकते हैं। किसी भी परिवर्तन से एक दिन पहले TTL कटौती की योजना बनाएं।
- एपेक्स पर CNAME, ज़ोन की जड़ (example.com स्वयं) पर CNAME रिकॉर्ड की अनुमति नहीं है। प्रदाता ALIAS या ANAME रिकॉर्ड वर्कअराउंड के रूप में प्रदान करते हैं, लेकिन ये मानक DNS नहीं हैं, इसलिए व्यवहार भिन्न होता है।
- कई SPF रिकॉर्ड को ढेर लगाना, SPF को v=spf1 से शुरू होने वाले बिल्कुल एक TXT रिकॉर्ड की आवश्यकता होती है। दो SPF रिकॉर्ड प्राप्त सर्वरों को परिणाम को PermError के रूप में चिह्नित करने पर मजबूर करते हैं, जो डिलीवरी को डुबो देता है।
- अंतिम बिंदु भूलना, ज़ोन फ़ाइलों में, अंतिम बिंदु के बिना नाम ज़ोन के सापेक्ष माने जाते हैं, इसलिए बिंदु भूलने से mail.example.com mail.example.com.example.com में बदल जाता है।
- IPv4 और IPv6 A रिकॉर्ड मिलाना, A केवल IPv4 के लिए है। A रिकॉर्ड में IPv6 पता डालना (AAAA के बजाय) एक कॉन्फ़िगरेशन त्रुटि है जिसे कुछ UI पकड़ नहीं पाते।
- CNAME श्रृंखलाएं जो लूप करती हैं, एक CNAME जो दूसरे CNAME की ओर इशारा करता है जो वापस इशारा करता है, एक रिज़ॉल्यूशन लूप बनाता है। रिज़ॉल्वर हार मानने से पहले श्रृंखला को लगभग आठ हॉप पर सीमित करते हैं।
- कई परतों पर कैशिंग, ब्राउज़र, OS, राउटर और रिज़ॉल्वर प्रत्येक स्वतंत्र रूप से DNS कैश करते हैं। केवल एक को फ़्लश करना शायद ही पर्याप्त होता है; श्रृंखला को पूरी तरह से बायपास करने के लिए लुकअप टूल का उपयोग करें।
- वाइल्डकार्ड रिकॉर्ड गायब प्रविष्टियों को छुपाते हैं, एक वाइल्डकार्ड A रिकॉर्ड (*.example.com) किसी भी सबडोमेन से मेल खाएगा जिसका कोई स्पष्ट रिकॉर्ड नहीं है, जो गलत कॉन्फ़िगरेशन को छुपा सकता है।
- केवल एक रिज़ॉल्वर पर भरोसा करना, प्रसार असमान होता है। वैश्विक परिवर्तन की पुष्टि करते समय कुछ रिज़ॉल्वर (1.1.1.1, 8.8.8.8, 9.9.9.9) से क्वेरी करें।
DNS क्वेरी के अन्य तरीके
ब्राउज़र-आधारित लुकअप टूल अधिकांश जांचों के लिए सबसे तेज़ रास्ता है, लेकिन कमांड-लाइन टूल जब आपको आवश्यकता हो तो समृद्ध विवरण देते हैं।
| टूल | प्लेटफ़ॉर्म | ताकत | कमज़ोरी |
|---|---|---|---|
| वेब लुकअप टूल | ब्राउज़र (कोई भी OS) | तेज़, इंस्टॉल नहीं, आउटपुट फ़ॉर्मेट करता है | सामान्य रिकॉर्ड प्रकारों तक सीमित |
| dig | macOS, Linux, Windows (WSL) | सबसे संपूर्ण आउटपुट, पूर्ण RFC निष्ठा | वर्बोज़, सिंटैक्स झंझटी |
| nslookup | सभी प्रमुख OS | हर OS के साथ बंडल, इंटरैक्टिव मोड | आउटपुट विरल, व्याख्या भिन्न |
| host | macOS, Linux | A/AAAA/MX का संक्षिप्त सारांश | dig से कम विवरण |
| drill | BSD, Linux | dig का DNSSEC-जागरूक विकल्प | कम सामान्य, छोटा समुदाय |
| "what's my DNS" साइटें | ब्राउज़र | क्षेत्रों में प्रसार दिखाती हैं | अक्सर विज्ञापन-भारी, कोई बैच लुकअप नहीं |
प्रत्येक के अपने समझौते हैं। dig +trace जड़ों से DNS पेड़ चलाता है और हर कदम दिखाता है, जो यह साबित करने के लिए अमूल्य है कि श्रृंखला कहां टूटती है। nslookup हर जगह है और त्वरित स्वच्छता जांच के लिए ठीक है। वेब टूल गति और कोई टर्मिनल नहीं चाहिए होने में जीतता है।
गोपनीयता और DNS
सादा DNS क्वेरीज़ क्लियरटेक्स्ट में यात्रा करती हैं, जिसका अर्थ है कि आपका ISP और नेटवर्क पर कोई भी हर डोमेन देख सकता है जिसे आप विज़िट करते हैं। दो एन्क्रिप्टेड विकल्प इसका समाधान करते हैं: DNS-over-HTTPS (DoH) क्वेरीज़ को HTTPS में लपेटता है, और DNS-over-TLS (DoT) उन्हें एक समर्पित पोर्ट पर TLS में लपेटता है। लुकअप टूल Cloudflare के DoH एंडपॉइंट का उपयोग करता है, इसलिए रिज़ॉल्वर के लिए आपकी क्वेरी ट्रांज़िट में एन्क्रिप्टेड है। जिस डोमेन के बारे में आप पूछते हैं वह रिज़ॉल्वर के लिए दृश्यमान बना रहता है; यदि यह आपको चिंतित करता है, तो अपना खुद का रिज़ॉल्वर चलाएं (Unbound, Pi-hole) या एक भुगतान गोपनीयता-केंद्रित सेवा का उपयोग करें जो लॉग न करने का वादा करती है।
ब्राउज़र-आधारित लुकअप कभी भी आपके अनुरोधों को हमारे सर्वरों पर संग्रहीत नहीं करते। अनुरोध आपके ब्राउज़र से सीधे DoH रिज़ॉल्वर तक जाता है और प्रतिक्रिया क्लाइंट-साइड रेंडर होती है। न तो सम्मन के लिए कोई लॉग है, न ही इस बारे में विश्लेषण कि आपने कौन से डोमेन की जांच की, और न ही भविष्य की उल्लंघन में लीक होने के लिए कुछ है। DNS डीबगिंग जितने नियमित कार्य के लिए, यह बिल्कुल वह गोपनीयता स्तर है जिसका काम हकदार है।
अक्सर पूछे जाने वाले प्रश्न
DNS क्या है?
DNS (Domain Name System) example.com जैसे डोमेन नामों को 93.184.216.34 जैसे IP पतों में अनुवादित करता है जिनका उपयोग कंप्यूटर एक-दूसरे से कनेक्ट करने के लिए करते हैं। इसे अक्सर इंटरनेट की «फ़ोन बुक» कहा जाता है।
A रिकॉर्ड क्या है?
एक A रिकॉर्ड एक डोमेन नाम को एक IPv4 पते से जोड़ता है। जब आप एक साइट पर जाते हैं, तो आपका ब्राउज़र A रिकॉर्ड खोजने और उस IP पर कनेक्ट करने के लिए DNS लुकअप करता है।
A और AAAA रिकॉर्ड्स में क्या अंतर है?
A रिकॉर्ड्स IPv4 पतों पर इशारा करते हैं (उदाहरण के लिए 93.184.216.34)। AAAA IPv6 पर इशारा करते हैं (उदाहरण के लिए 2606:2800:220:1:248:1893:25c8:1946)। अधिकांश आधुनिक साइटों में दोनों होते हैं।
MX रिकॉर्ड्स किस लिए हैं?
MX (Mail Exchange) रिकॉर्ड्स उन सर्वरों को निर्दिष्ट करते हैं जो एक डोमेन के लिए मेल संभालते हैं। जब कोई user@example.com को लिखता है, तो भेजने वाला सर्वर example.com के MX से परामर्श करता है ताकि पता चले कि मेल कहाँ डिलीवर करना है।
Why do DNS changes take so long to propagate?
When you change a DNS record, resolvers around the world keep serving the previous value until the cached entry's TTL (Time to Live) expires. TTLs commonly range from 5 minutes to 24 hours. Lowering the TTL a day before a planned change helps the new value appear faster.
What is the difference between authoritative and recursive DNS?
An authoritative nameserver is the official source of truth for a domain. A recursive resolver (your ISP, Google 8.8.8.8, Cloudflare 1.1.1.1) is what your device queries; it walks the DNS tree and caches answers. A DNS lookup tool typically queries a recursive resolver, which forwards the question to the authoritative server.