DNS रिकॉर्ड लुकअप
डोमेन जो भी रिकॉर्ड प्रकाशित करता है, और उनसे उसके मेल और सर्टिफ़िकेट के बारे में क्या पता चलता है।
रिकॉर्ड, और वे असल में किस काम के हैं
| प्रकार | किस पर इशारा | कब सामने आता है |
|---|---|---|
A | IPv4 पता | हमेशा। डोमेन को खुलवाने वाला यही है। |
AAAA | IPv6 पता | बढ़ते हुए। मोबाइल नेटवर्क अक्सर सिर्फ़ IPv6 वाले होते हैं। |
CNAME | कोई दूसरा नाम | www को शीर्ष पर, या किसी सबडोमेन को किसी SaaS प्रदाता पर भेजते समय। |
MX | मेल सर्वर, प्राथमिकता के साथ | जब मेल नहीं आ रही हो। कम प्राथमिकता संख्या जीतती है। |
NS | ज़ोन के आधिकारिक नेमसर्वर | आपने प्रदाता बदला है और जानना है कि जवाब अब किसका मिल रहा है। |
TXT | मुक्त रूप का टेक्स्ट | SPF, DKIM, DMARC, और हर वह डोमेन-सत्यापन टोकन जो आपने कभी चिपकाया। |
SOA | ज़ोन का मेटाडेटा और टाइमर | नेमसर्वरों के बीच प्रतिकृति की जाँच करते समय। |
CAA | अनुमत सर्टिफ़िकेट अथॉरिटी | यह सीमित करते समय कि आपके लिए प्रमाणपत्र कौन जारी कर सकता है। |
«प्रोपेगेशन» ग़लत शब्द है
DNS के बारे में समझने लायक़ सबसे काम की बात, क्योंकि यह एक अनिश्चित इंतज़ार को ऐसी संख्या में बदल देती है जो आपके हाथ में है।
कुछ भी फैलता नहीं। न कोई पुश, न वितरण, न अपडेट की कोई लहर जो इंटरनेट पर दौड़ती हो। जिस पल आप सहेजते हैं, उसी पल आपके नेमसर्वर के पास नया मान आ जाता है। समय जिस चीज़ में लगता है वह यह है कि दुनिया का हर रिज़ॉल्वर पुराने जवाब की एक कैश की गई प्रति रखे बैठा है, और हर एक उसे तब तक रखेगा जब तक उसे दिया गया TTL ख़त्म न हो जाए।
तो यह देरी रहस्यमय नहीं है — यह ठीक वही TTL है जो तब प्रकाशित था जब हर रिज़ॉल्वर ने आख़िरी बार पूछा था। अगर आपके रिकॉर्ड का TTL 3600 सेकंड था, तो कुछ रिज़ॉल्वर पाँच मिनट में दोबारा पूछेंगे और कुछ एक घंटे में — इसीलिए लगता है कि बदलाव लोगों तक असमान रूप से पहुँच रहा है।
इससे किसी भी तयशुदा बदलाव की प्रक्रिया निकल आती है:
- एक दिन पहले TTL घटाकर 300 सेकंड कर दीजिए। पुराने TTL के ख़त्म होने का इंतज़ार कीजिए ताकि सबने छोटा वाला उठा लिया हो।
- अब बदलाव कीजिए। अब इसमें एक दिन नहीं, पाँच मिनट लगेंगे।
- जब सब जम जाए, तो TTL वापस बढ़ा दीजिए।
वापस बढ़ाने की वजह यह है कि कम TTL का मतलब है ज़्यादा क्वेरियाँ, कैश मिस पर ज़्यादा विलंबता, और अगर आपके नेमसर्वर पहुँच से बाहर हो जाएँ तो कहीं भारी आउटेज — क्योंकि किसी के पास सहारा लेने लायक़ कोई कैश किया जवाब बचा ही नहीं होगा।
मेल वाले रिकॉर्ड, जहाँ ज़्यादातर समस्याएँ होती हैं
तीन TXT रिकॉर्ड तय करते हैं कि आपकी मेल पर भरोसा किया जाए या नहीं। इन्हें अक्सर ग़लत सेट किया जाता है और नाकामी ख़ामोश होती है — मेल बाउंस होने के बजाय स्पैम में चली जाती है, इसलिए कोई आपको बताता ही नहीं।
SPF
यह गिनाता है कि आपके डोमेन के लिए कौन-से सर्वर मेल भेज सकते हैं। ग़लतियाँ, बारंबारता के क्रम में:
- दो SPF रिकॉर्ड। RFC 7208 पाने वालों से अपेक्षा करता है कि वे इसे स्थायी त्रुटि मानें, इसलिए जाँच पूरी तरह नाकाम हो जाती है। दोनों को मिलाकर एक कर दीजिए।
- दस से ज़्यादा DNS लुकअप। हर
include:गिना जाता है, और include एक-दूसरे के भीतर घुसते हैं। एक मेल प्रदाता, एक मार्केटिंग प्लेटफ़ॉर्म और एक हेल्पडेस्क मिलकर आपको वहाँ जल्दी पहुँचा देते हैं, और सीमा पार होते ही जाँच नाकाम। - `~all` या `?all` पर ख़त्म होना। दोनों का मतलब है «शायद हम नहीं, पर जैसा ठीक लगे कीजिए»। पाने वालों से ठुकराने को सिर्फ़
-allकहता है।
DKIM और DMARC
DKIM हर संदेश पर ऐसी कुंजी से हस्ताक्षर करता है जिसका सार्वजनिक हिस्सा किसी सिलेक्टर नाम — जैसे selector1._domainkey.example.com — पर TXT रिकॉर्ड में रहता है; उसे देखने के लिए सिलेक्टर पता होना चाहिए, और इसीलिए वह ऊपर की डिफ़ॉल्ट क्वेरी में नहीं है। DMARC _dmarc.example.com पर रहता है और पाने वालों को बताता है कि SPF और DKIM में मतभेद हो तो क्या करें, और रिपोर्ट कहाँ भेजें।
ऊपर वाले टूल में _dmarc.yourdomain.com देखिए। अगर कुछ नहीं लौटता, तो पाने वालों के पास कोई निर्देश ही नहीं है और आपके नाम की नक़ल करने वाली किसी भी मेल पर वे अपनी समझ लगाएँगे।
शीर्ष पर CNAME का नियम
एक ही नाम के लिए CNAME किसी और रिकॉर्ड के साथ नहीं रह सकता। और डोमेन के शीर्ष पर SOA तथा NS रिकॉर्ड होने ही चाहिए, इसलिए शीर्ष पर CNAME हो ही नहीं सकता — यही वजह है कि example.com को किसी SaaS प्रदाता पर भेजना टेढ़ा है जबकि www.example.com बेहद आसान।
इसके तोड़ प्रदाता के हिसाब से अलग हैं: ALIAS, ANAME या CNAME फ़्लैटनिंग — ये सब लक्ष्य को सर्वर की तरफ़ हल करते हैं और A रिकॉर्ड से जवाब देते हैं। ये चलते हैं, ये मानक नहीं हैं, और इन पर एक पूरी दोपहर ख़र्च करने से पहले इनका पता होना चाहिए।
संबंधित
जब रिकॉर्ड वहीं इशारा करने लगें जहाँ आपका इरादा था, तो उस सर्टिफ़िकेट की जाँच कीजिए जो होस्ट असल में पेश करता है, और वह कौन-से हेडर लौटाता है यह भी। और जिस पते पर कोई रिकॉर्ड इशारा कर रहा है वह किस नेटवर्क का है, इसका जवाब ASN लुकअप देता है।
DNS से जुड़े सवाल
मैंने रिकॉर्ड बदला, फिर भी पुराना मान दिख रहा है। क्यों?
कैशिंग, और वह भी कई परतों पर। हर रिकॉर्ड का एक TTL होता है जो बताता है कि रिज़ॉल्वर उसे कितनी देर रख सकते हैं, और जब तक वह ख़त्म नहीं होता आपको पुराना ही जवाब दिखेगा, चाहे आधिकारिक सर्वर अब कुछ भी कह रहा हो। उसके ऊपर आपका ऑपरेटिंग सिस्टम और ब्राउज़र भी कैश करते हैं। यहाँ की जाँच आधिकारिक नेमसर्वर से सीधे नहीं, बल्कि एक रिज़ॉल्वर से होती है, इसलिए उसे भी कैश किए मान दिखते हैं। असल में क्या प्रकाशित है यह जानने के लिए डोमेन के अपने नेमसर्वर से सीधे पूछिए: dig @ns1.example.com example.com A।
DNS प्रोपेगेशन में कितना समय लगता है?
प्रोपेगेशन जैसी कोई चीज़ है ही नहीं — यह शब्द ही भ्रम की जड़ है। कुछ भी कहीं धकेला नहीं जाता। रिज़ॉल्वर बस अपनी कैश की गई प्रति तब तक रखते हैं जब तक उसका TTL ख़त्म न हो, फिर दोबारा पूछते हैं; इसलिए आपको जो देरी महसूस होती है वह ठीक वही TTL है जो उनके पिछली बार पूछने के वक़्त प्रकाशित था। तय बदलाव से एक दिन पहले TTL घटा दीजिए और बदलाव घंटों के बजाय मिनटों में हो जाएगा; भूल गए, तो 24 घंटे का TTL यानी पूरा एक दिन जिसमें कुछ आगंतुकों को पुराना मान दिखता रहेगा।
CAA रिकॉर्ड क्या है और क्या मुझे चाहिए?
यह बताता है कि आपके डोमेन के लिए प्रमाणपत्र कौन-कौन-सी सर्टिफ़िकेट अथॉरिटी जारी कर सकती हैं, और CA को जारी करने से पहले इसे देखना अनिवार्य है। इसके बिना दुनिया की कोई भी सार्वजनिक CA आपके डोमेन के लिए जारी कर सकती है — यानी सौ में से किसी एक CA की सत्यापन प्रक्रिया तोड़ लेने वाला हमलावर वैध प्रमाणपत्र पा जाता है। इसके साथ हमले की सतह सिमटकर सिर्फ़ उन्हीं CA तक रह जाती है जिनके नाम आपने लिखे। यह एक पंक्ति है और जोड़ने लायक़ है।
मेरा SPF रिकॉर्ड सही दिखता है फिर भी नाकाम क्यों होता है?
तीन आम वजहें। एक ही डोमेन पर दो SPF रिकॉर्ड RFC 7208 के तहत स्थायी त्रुटि हैं और पूरी जाँच नाकाम कर देते हैं — ठीक एक ही प्रकाशित कीजिए। दस DNS लुकअप से आगे जाना भी नाकाम करता है (हर include: गिना जाता है, और include एक-दूसरे के भीतर घुसते हैं); एक मेल प्रदाता, एक मार्केटिंग टूल और एक हेल्पडेस्क होते ही यह सीमा सुनने से कहीं जल्दी छू जाती है। और ~all या ?all पर ख़त्म करना पाने वालों को निर्देश नहीं, बस सलाह देता है, इसलिए दूसरे होस्ट से आई मेल अक्सर वैसे भी पहुँच जाती है।
A रिकॉर्ड और CNAME में क्या फ़र्क़ है?
A रिकॉर्ड किसी नाम को सीधे एक IPv4 पते पर भेजता है। CNAME किसी नाम को दूसरे नाम पर भेजता है, जिसे फिर अपनी बारी में हल करना पड़ता है। जो नियम लोगों को फँसाता है वह यह है कि एक ही नाम के लिए CNAME किसी और रिकॉर्ड के साथ नहीं रह सकता — यानी डोमेन का शीर्ष (apex), जिसमें SOA और NS रिकॉर्ड होने ही चाहिए, CNAME नहीं रख सकता। प्रदाता इससे बचने के लिए ALIAS या ANAME रिकॉर्ड देते हैं, जो शीर्ष पर CNAME जैसा बरताव करते हैं पर सर्वर की तरफ़ हल होते हैं।
यह कौन-सा रिज़ॉल्वर इस्तेमाल करता है?
हमारे सर्वर का अपना, और यह जान-बूझकर है। 8.8.8.8 जैसे किसी तय सार्वजनिक रिज़ॉल्वर से पूछने पर वही रिपोर्ट होता जो Google को दिखता है, न कि वह जो एक साधारण क्लाइंट को दिखता है — और ये दोनों उम्मीद से ज़्यादा बार अलग होते हैं: भौगोलिक रूप से बँटे जवाब, स्प्लिट-होराइज़न DNS और रिज़ॉल्वर स्तर की फ़िल्टरिंग, तीनों यही अंतर पैदा करते हैं।
DNS is also the part of your own browsing that is most often unencrypted. Which resolver answers your queries determines who can see every domain you visit, whatever else is encrypted. Test which resolver you are really using
अंतिम समीक्षा । कुछ पुराना पड़ा हुआ मिला? हमें बताइए.