ज़्यादातर लोग DNS के बारे में तभी सोचते हैं जब कुछ गड़बड़ हो जाए। वेबसाइट आपके लिए खुलती है लेकिन आपके क्लाइंट के लिए नहीं। जिस दिन आपने प्रोवाइडर बदला, उसी दिन से ईमेल आना बंद हो गया। Google Search Console बार-बार कहता है कि वह आपका डोमेन verify नहीं कर पा रहा। आप अपनी DNS सेटिंग खोलते हैं और A, CNAME और TXT जैसे नामों वाले रिकॉर्ड की एक टेबल को घूरते रह जाते हैं, और लगता है जैसे यह कोई ऐसी भाषा है जो किसी ने सिखाई ही नहीं।
यह जितना दिखता है उससे आसान है। DNS इंटरनेट की पता-पुस्तिका है, और हर रिकॉर्ड टाइप एक ख़ास सवाल का जवाब देता है। एक बार आप जान लें कि कौन सा रिकॉर्ड किस सवाल का जवाब देता है, तो DNS की ज़्यादातर समस्याएँ साफ़ हो जाती हैं।
DNS असल में क्या करता है
कंप्यूटर एक-दूसरे को IP पते से ढूँढते हैं, जो 93.184.215.14 जैसा एक नंबर होता है। लोगों को example.com जैसे नाम पसंद हैं। DNS, यानी Domain Name System, एक को दूसरे में बदलता है।
जब कोई ब्राउज़र में आपका डोमेन टाइप करता है, तो उसका डिवाइस एक DNS resolver से पूछता है, जो आम तौर पर उसका इंटरनेट प्रोवाइडर, Google या Cloudflare चलाता है। resolver आपके डोमेन के लिए ज़िम्मेदार name servers ढूँढता है और उनसे सही रिकॉर्ड माँगता है। जवाब वापस आता है, ब्राउज़र कनेक्ट होता है, और पेज लोड हो जाता है। इसमें आम तौर पर कुछ मिलीसेकंड लगते हैं।
अहम बात: आपके DNS रिकॉर्ड आपके डोमेन के name servers पर रहते हैं, और जो भी उन name servers को चलाता है, बदलाव वहीं करने होते हैं। यह एक बात हैरान कर देने वाली संख्या में समस्याएँ हल कर देती है।
वे रिकॉर्ड जो आप असल में इस्तेमाल करेंगे
| रिकॉर्ड | किस सवाल का जवाब देता है | आम उदाहरण |
|---|---|---|
| A | यह नाम किस IPv4 पते पर है? | example.com → 93.184.215.14 |
| AAAA | यह किस IPv6 पते पर है? | example.com → 2606:2800:… |
| CNAME | यह नाम किस दूसरे नाम का उपनाम है? | www.example.com → example.com |
| MX | इस डोमेन का ईमेल कौन से सर्वर पाते हैं? | 10 mail.provider.com |
| TXT | इसके लिए कौन से टेक्स्ट नोट प्रकाशित हैं? | SPF, DMARC, verification कोड |
| NS | इसके लिए कौन से name servers ज़िम्मेदार हैं? | ns1.host.com |
| CAA | कौन सी certificate authorities इसके लिए SSL जारी कर सकती हैं? | 0 issue "letsencrypt.org" |
A और AAAA: वेबसाइट कहाँ रहती है
A रिकॉर्ड किसी नाम को IPv4 पते की ओर इशारा करता है; AAAA यही IPv6 के लिए करता है। जब आप होस्टिंग बदलते हैं, तो आम तौर पर यही रिकॉर्ड बदलते हैं।
CNAME: एक उपनाम, पता नहीं
CNAME कहता है "यह नाम उस नाम जैसा ही है", और पता target से खोजा जाता है। ये उन subdomains के लिए बढ़िया हैं जो किसी सेवा की ओर इशारा करते हैं, जैसे shop.example.com किसी ई-कॉमर्स प्लेटफ़ॉर्म की ओर। एक नियम लोगों को उलझा देता है: जिस नाम पर CNAME है, उस पर कोई दूसरा रिकॉर्ड नहीं हो सकता। इसीलिए root domain (ख़ुद example.com) पर आम तौर पर CNAME नहीं, A रिकॉर्ड इस्तेमाल होते हैं।
MX: ईमेल कहाँ जाता है
MX रिकॉर्ड उन सर्वरों की सूची देते हैं जो आपके डोमेन का ईमेल पाते हैं, हर एक के साथ एक priority नंबर। कम नंबर पहले आज़माए जाते हैं। अगर किसी बदलाव के बाद ईमेल आना बंद हो जाए, तो सबसे पहले ग़ायब या ग़लत MX रिकॉर्ड जाँचें।
TXT: सबूत और नीति
TXT रिकॉर्ड में वह टेक्स्ट होता है जिसे दूसरी सेवाएँ पढ़ती हैं। सबसे अहम वाले ईमेल पर भरोसे से जुड़े हैं:
- SPF
v=spf1से शुरू होता है और बताता है कि कौन से सर्वर आपके डोमेन की ओर से ईमेल भेज सकते हैं। एक डोमेन पर ठीक एक SPF रिकॉर्ड होना चाहिए। - DKIM
selector._domainkey.yourdomain.comपर एक public key प्रकाशित करता है ताकि पाने वाले आपके ईमेल सिग्नेचर verify कर सकें। selector का नाम आपका ईमेल प्रोवाइडर बताता है। - DMARC
_dmarc.yourdomain.comपर रहता है और पाने वालों को बताता है कि SPF और DKIM जाँच में फ़ेल होने वाले ईमेल के साथ क्या करें।
TXT रिकॉर्ड से ही आप Google Search Console और Microsoft 365 जैसी सेवाओं को मालिकाना हक़ साबित करते हैं।
TTL और "propagation": बदलाव धीमे क्यों लगते हैं
हर रिकॉर्ड का एक TTL होता है, यानी time to live, सेकंड में मापा गया। यह resolvers को बताता है कि वे जवाब को कितनी देर तक cache कर सकते हैं। 3600 के TTL का मतलब है कि जिस resolver ने आपका रिकॉर्ड देखा है, वह आपके बदलने के बाद भी एक घंटे तक पुरानी वैल्यू इस्तेमाल कर सकता है।
इसे ही लोग DNS propagation कहते हैं। कुछ भी धीरे-धीरे दुनिया में नहीं घूम रहा; बस caches अलग-अलग समय पर expire हो रहे हैं। ज़्यादातर बदलाव कुछ मिनटों से लेकर कुछ घंटों में दिखने लगते हैं। name servers बदलने में ज़्यादा समय लग सकता है, 48 घंटे तक, क्योंकि वे रिकॉर्ड ऊँचे स्तर पर cache होते हैं।
एक व्यावहारिक तरीक़ा: किसी योजनाबद्ध बदलाव से एक दिन पहले, जिन रिकॉर्ड को बदलना है उनका TTL घटाकर 300 सेकंड जैसा कम कर दें। जब आप बदलाव करेंगे, तो caches पाँच मिनट में expire हो जाएँगे। सब ठीक चलने के बाद उसे फिर बढ़ा दें।
समस्या समाधान: आम समस्याएँ और क्या जाँचें
वेबसाइट मेरे लिए चलती है लेकिन दूसरों के लिए नहीं (या इसका उल्टा)
आप में से कोई एक cache किया गया, पुराना जवाब देख रहा है। DNS Lookup टूल से A रिकॉर्ड देखें, जो सीधे Google और Cloudflare के public resolvers से पूछता है। अगर वह नया पता दिखाता है, तो बदलाव लाइव है और कुछ caches अभी expire नहीं हुए हैं। अलग-अलग देशों के resolvers अभी क्या पा रहे हैं, यह देखने के लिए Ping & Uptime Checker से 30 से ज़्यादा जगहों से DNS जाँच चलाएँ; आपकी वेबसाइट बंद है या सिर्फ़ आपके लिए पर हमारी गाइड नतीजे पढ़ना समझाती है।
ईमेल आना बंद हो गया
MX देखें। अगर वह ख़ाली है या अब भी पुराने प्रोवाइडर की ओर इशारा करता है, तो उसे अपने DNS होस्ट पर ठीक करें। फिर SPF TXT रिकॉर्ड जाँचें: प्रोवाइडर बदलने के बाद उसमें अक्सर अब भी सिर्फ़ पुराना प्रोवाइडर लिखा होता है, इसलिए नए भेजे गए ईमेल spam में चले जाते हैं।
मेरे DNS बदलावों का कोई असर ही नहीं होता
शायद आप ग़लत जगह रिकॉर्ड एडिट कर रहे हैं। NS रिकॉर्ड देखें, या डोमेन के WHOIS रिकॉर्ड में name servers जाँचें। अगर वे Cloudflare की ओर इशारा करते हैं, तो आपके registrar पर किए बदलाव अनदेखे होते हैं, और इसका उल्टा भी। WHOIS रिकॉर्ड पढ़ने पर हमारी गाइड ठीक-ठीक दिखाती है कि name servers कहाँ दिखते हैं।
डोमेन verification बार-बार फ़ेल होता है
सेवा ने जिस सटीक नाम के लिए कहा था, उसके TXT रिकॉर्ड देखें। आम ग़लतियाँ हैं root domain के बजाय www पर रिकॉर्ड जोड़ना, या वैल्यू को अतिरिक्त quotes या spaces के साथ पेस्ट करना।
SSL सर्टिफ़िकेट renew नहीं होता
CAA देखें। अगर डोमेन पर CAA रिकॉर्ड हैं और उनमें से कोई भी आपके सर्टिफ़िकेट प्रोवाइडर की अनुमति नहीं देता, तो renewal फ़ेल हो जाता है। या तो CAA रिकॉर्ड हटाएँ या अपने प्रोवाइडर के लिए एक जोड़ें।
"Domain does not exist"
lookup ने NXDOMAIN लौटाया। हो सकता है डोमेन की स्पेलिंग ग़लत हो, वह रजिस्टर न हो, या expire हो गया हो। WHOIS Lookup से उसका रजिस्ट्रेशन और expiry की तारीख़ जाँचें।
किसी भी DNS बदलाव से पहले एक शांत चेकलिस्ट
- मौजूदा रिकॉर्ड लिख लें, या स्क्रीनशॉट ले लें, ताकि ज़रूरत पड़ने पर वापस जा सकें।
- पक्का करें कि कौन से name servers ज़िम्मेदार हैं, और रिकॉर्ड वहीं एडिट करें।
- अगर कुछ अहम बदल रहे हैं, तो एक दिन पहले TTL घटा दें।
- एक बार में एक बदलाव करें और तुरंत उसे देखें।
- ईमेल को वेबसाइट से अलग टेस्ट करें; दोनों अलग-अलग रिकॉर्ड पर निर्भर हैं।
- होस्टिंग बदलने के बाद Redirect Checker से redirects और HTTPS भी जाँचें।
अगर आप डोमेन को अपने चलाए किसी सर्वर की ओर कर रहे हैं, जैसे Docker से डिप्लॉय किया गया कोई ऐप, तो DNS को दोष देने से पहले पक्का करें कि ख़ुद स्टैक ठीक चल रहा है; Docker Compose की आम ग़लतियों पर हमारी गाइड वे ग़लतियाँ बताती है जो सबसे ज़्यादा डिप्लॉयमेंट रोकती हैं।
DNS को देख पाने के बाद उसका डर ख़त्म हो जाता है
DNS को लेकर ज़्यादातर घबराहट आँख मूँदकर बदलाव करने और फिर इंतज़ार करने से आती है कि क्या होता है। सार्वजनिक इंटरनेट रिकॉर्ड दर रिकॉर्ड ठीक-ठीक क्या देखता है, यह देख पाना इसे साधारण समस्या समाधान में बदल देता है।
अगली बार जब किसी बदलाव के बाद कुछ काम करना बंद कर दे, तो उस सवाल से शुरू करें जिस पर टूटी हुई चीज़ निर्भर है: वेबसाइट कहाँ है (A), ईमेल कहाँ जाता है (MX), यह डोमेन क्या वादा करता है (TXT), और ज़िम्मेदार कौन है (NS)। फिर DNS Lookup टूल से उसे देखें और अपनी उम्मीद से मिलाएँ। जवाब आम तौर पर वहीं टेबल में होता है।
