जब Google की सार्वजनिक डीएनएस सेवा, किसी डोमेन को ठीक नहीं कर पाती है, तो ऐसा उस डोमेन या इसके आधिकारिक नाम सर्वर में किसी समस्या की वजह से होता है. इन चरणों की मदद से यह पता लगाया जा सकता है कि समस्या किस वजह से हुई है, ताकि डोमेन एडमिन इसे खुद ही हल कर सकें.
शुरू करने से पहले, dns.google पर डोमेन की जांच करें. इसके बारे में सामान्य समस्या को हल करने वाले पेज पर बताया गया है. यहां इसका तरीका बताया गया है. अगर ऐसा नहीं होता है, तो जब तक वजह नहीं मिलती, तब तक नीचे दिए गए सभी चरणों को आज़माएं.
पहला चरण: डीएनएसएसईसी की पुष्टि से जुड़ी समस्याओं की जांच करना
अगर डोमेन के लिए dns.google वेब लुकअप के नतीजे, "Status": 2 (SERV आखिर) और बिना डीएनएसएसईसी वाली क्वेरी दिखते हैं, तो डोमेन और # 99 नाम के टीएलडी के साथ डीएनएसएसईसी में समस्या हो सकती है. इससे डीएनएसएसईसी की पुष्टि के लिए रजिस्टर किए गए डोमेन रिकॉर्ड हो जाते हैं.
- रजिस्ट्रार या डीएनएस सेवा में बदलाव
डीएनएसएसईसी से जुड़ी समस्याएं, किसी ऐसे रजिस्ट्रार या डीएनएस सेवा के डोमेन पर स्विच करने के बाद हो सकती हैं जो डीएनएसएसईसी के साथ काम करता है. अगर पिछली सेवा, टीएलडी रजिस्ट्री में पुराने
DSरिकॉर्ड छोड़ देती है और नई सेवा, टीएलडी रजिस्ट्री मेंDSरिकॉर्ड से मेल खाने वालेDSरिकॉर्ड नहीं बनाती है, तो Google की सार्वजनिक डीएनएस जैसी रिज़ॉल्वर की पुष्टि करने से डोमेन का समाधान नहीं हो सकता.अगर ऐसा होता है, तो अपने डोमेन रजिस्ट्रार से कहें कि वह टीएलडी रजिस्ट्री से पुराने डीएस रिकॉर्ड हटा दें.
- डीएनएसएसईसी से जुड़े जवाब बहुत ज़्यादा हैं
डीएनएसएसईसी से जुड़ी समस्याओं की एक और वजह, डीएनएसएसईसी के ऐसे जवाब हो सकते हैं जो एक ही आईपी पैकेट में फ़िट नहीं हो पाते. इससे, फ़्रैगमेंट वाले ऐसे रिस्पॉन्स बनते हैं जो छूटे जा सकते हैं. अगर DNSViz दिखाता है और कोट के आकार का इस्तेमाल करके यूडीपी पेलोड का साइज़ कम करने तक कोई रिस्पॉन्स नहीं मिलता है, तो हो सकता है कि बहुत ज़्यादा रिस्पॉन्स मिलने पर डीएनएसएसईसी से जुड़ी गड़बड़ियां न आएं. जवाब के साइज़ को इनमें से एक या ज़्यादा कार्रवाइयों के ज़रिए कम किया जा सकता है:
- आधिकारिक नेम सर्वर के लिए कम से कम रिस्पॉन्स और कोटेशन को कॉन्फ़िगर करना
- चालू
DNSKEYरिकॉर्ड की संख्या को दो या तीन तक कम करें - 1280 या 2048 बिट
DNSKEYरिकॉर्ड (आरएफ़सी 6781, StackExchange) का इस्तेमाल करें - आरएसए हस्ताक्षर से छोटे ECDSA हस्ताक्षर पर स्विच करें (आरएफ़सी 8624)
साथ ही, दूसरे चरण में दिए गए टूल से, डीएनएसएसईसी से जुड़ी अन्य समस्याओं की जांच करें. उदाहरण के लिए, ऐसे एनएसईसी या एनएसईसी3 के अस्वीकार किए जाने के रिकॉर्ड शामिल हैं जिनमें साबित किया गया हो कि कोई सबडोमेन नहीं है (बाहरी डेटाबेस में सेव किए गए ज़ोन के साथ PowerDNS) में ये सब हो सकते हैं. इसके अलावा, मैन्युअल तरीके से कॉन्फ़िगर की गई साइनिंग प्रोसेस के साथ, आरआरएसआईजी हस्ताक्षर की समयसीमा खत्म हो चुकी है.
दूसरा चरण: आधिकारिक नेम सर्वर की जांच करना
अगर Google की सार्वजनिक डीएनएस सेवा (या किसी भी ओपन रिज़ॉल्वर) में किसी डोमेन को ठीक करने में समस्या आती है, तो DNSViz इससे डोमेन और नाम सर्वर की समस्याएं दिखती हैं. DNSViz वेब पेज पर जाएं और समस्या वाला डोमेन नाम डालें. अगर DNSViz का कोई पुराना डेटा नहीं है या उसमें सिर्फ़ एक दिन से ज़्यादा पुराना डेटा है (जैसे, यहां पेज पर दिखाया गया है), तो नीचे दिए गए, 'विश्लेषण करें' बटन को देखने के लिए, विश्लेषण करें बटन पर क्लिक करें. अगर बटन पहले से दिखाई नहीं दे रहा है, तो उस पर क्लिक करें. विश्लेषण पूरा होने पर, नतीजे दिखाने के लिए "जारी रखें" और "कोट करें" पर क्लिक करें. जानकारी दिखाने के लिए बाएं साइडबार पर लाल रंग की गड़बड़ियां और पीले रंग की चेतावनियां क्लिक करें या जानकारी में पॉइंटर को ऑब्जेक्ट में दिखाने के लिए उसे डायग्राम में रखें.
अगर पहले के डाइग्नोस्टिक्स से डोमेन के लिए डीएनएसएसईसी की संभावित समस्याओं का पता चलता था, तो
डीएनएसएसईसी विश्लेषक के वेब पेज पर जाएं
और डोमेन नाम डालें. अगर यह विश्लेषक, डीएनएसएसईसी की गड़बड़ियों या चेतावनियों की शिकायत करता है, तो लाल रंग के
inDNS वेब पेज, मुख्य पेज पर डाले गए डोमेन से बिना डीएनएसएसईसी वाली समस्याओं की रिपोर्ट करता है. साथ ही, उन्हें ठीक करने के सुझाव भी दिखाता है.
डोमेन एडमिन को इन टूल रिपोर्ट में से ज़्यादातर गड़बड़ियों को ठीक करना चाहिए. ऐसा इसलिए, क्योंकि इनसे न सिर्फ़ Google की सार्वजनिक डीएनएस सेवा में, बल्कि दूसरे रिज़ॉल्वर में भी समस्याएं हो सकती हैं.
तीसरा चरण: डेलिगेशन से जुड़ी समस्याओं की जांच करना
Google की सार्वजनिक डीएनएस सेवा, एक "माता-पिता का ध्यान रखने वाले"रिज़ॉल्वर है, जो सिर्फ़ नाम वाले सर्वर का इस्तेमाल करता है. ये पैरंट डोमेन से मिले रेफ़रल में दिखाए जाते हैं. अगर टीएलडी में नाम सर्वर और ग्लू पते वाले पते पुराने हैं या गलत हैं, तो इससे डेलिगेशन से जुड़ी समस्याएं हो सकती हैं.
अगर टीएलडी में दिए गए नाम सर्वर और चाइल्ड डोमेन में मौजूद अलग-अलग सर्वर के बीच अंतर होने पर DNSViz या inDNS की रिपोर्ट में चेतावनियां दी जाती हैं, तो हो सकता है कि Google की सार्वजनिक डीएनएस सेवा से डोमेन को हल करने से पहले उन समस्याओं को ठीक करना पड़े. अगर इन टूल से यह पता चलता है कि रजिस्टर किया गया डोमेन मौजूद नहीं है (NXDOMAIN), तो देखें कि डोमेन की समयसीमा खत्म तो नहीं हुई है या वह किसी वजह से रजिस्ट्रेशन होल्ड पर है या नहीं.
किसी डोमेन के नाम सर्वर का नाम न ढूंढ पाने की वजह से भी, डेलिगेशन की समस्याओं का सामना करना पड़ सकता है. dns.google पर नाम सर्वर के लिए, A और AAAA रिकॉर्ड देखें. इससे यह पता चलता है कि नेम सर्वर और डोमेन में कोई समस्या है या नहीं.
चौथा चरण: बड़े जवाब देखना
डीएनएस, ज़्यादातर ट्रैफ़िक को ट्रांसफ़र करने के लिए, UDP पर निर्भर करता है. बड़े यूडीपी डेटाग्राम, फ़्रैगमेंटेशन और फ़्रैगमेंट वाले यूडीपी से प्रभावित होते हैं. यह डीएनएस फ़्लैग डे 2020 का फ़ोकस था. यह दुनिया भर में डीएनएस की विश्वसनीयता को बेहतर बनाने की एक कोशिश थी. Google की सार्वजनिक डीएनएस टीम ने इस कोशिश में हिस्सा लिया है. साथ ही, यूडीपी पर स्वीकार किए जाने वाले यूडीपी रिस्पॉन्स का साइज़ सीमित है. आप अपने कमांड प्रॉम्प्ट या Google Cloud Shell से नीचे दी गई क्वेरी आज़मा सकते हैं:
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
अलग-अलग तरह के रिकॉर्ड के लिए, ये क्वेरी पूछी जाती हैं:
+dnssec- डीएनएसएसईसी चालू करें, खास तौर पर डीएनएसएसईसी की पुष्टि के लिए ज़रूरी रिकॉर्ड उपलब्ध होने पर. इससे नतीजों का साइज़ बढ़ सकता है. यह Google सार्वजनिक डीएनएस के व्यवहार को एम्युलेट करता है.
+bufsize=1400- इस्तेमाल किए गए यूडीपी बफ़र का साइज़ सीमित करें. यह डीएनएस फ़्लैग डे 2020 की कोशिश के मुताबिक, Google सार्वजनिक डीएनएस और व्यवहार को एम्युलेट करता है.
+timeout=1- टाइम आउट एक सेकंड पर सेट करें. यह Google सार्वजनिक डीएनएस के व्यवहार को एम्युलेट करता है.
@ns1.example.com- क्वेरी करने के लिए कौनसा आधिकारिक सर्वर --
@साइन रखें, लेकिन इसे अपने डोमेन के आधिकारिक सर्वर से बदलें, जैसा कि पहले निर्देश में दिखाया गया है.
आउटपुट पर ध्यान दें; क्या आपको ऐसी लाइन दिख रही है:
;; Truncated, retrying in TCP mode.- इससे पता चलता है कि रिस्पॉन्स, अनुरोध किए गए यूडीपी बफ़र साइज़ से बड़ा था. इसलिए, इसे छोटा किया गया और रिस्पॉन्स के तौर पर क्लाइंट ने टीसीपी का इस्तेमाल किया. आपके आधिकारिक सर्वर पर, टीसीपी पोर्ट 53 पर डीएनएस ट्रैफ़िक को मैनेज करने की सुविधा होनी चाहिए. (आरएफ़सी 7766 देखें जिसके लिए और इसे लागू करने के लिए, यूडीपी और टीसीपी ट्रांसपोर्ट और कोट दोनों ज़रूरी हैं.)
;; MSG SIZE rcvd: 2198- 1400 से ऊपर की संख्या के लिए? इससे एक बड़ा जवाब मिलता है.
;; Query time: 727 msec- 500 से ऊपर के किसी भी नंबर के लिए? धीमे जवाब (खास तौर पर एक या उससे ज़्यादा सेकंड वाले) को Google सार्वजनिक डीएनएस के ज़रिए खारिज किया जा सकता है. ऐसा खास तौर पर तब होता है, जब यूडीपी की कोशिश में कुछ समय बिताया गया हो और इसके बाद, टीसीपी की कोशिश की गई हो. सर्वर की जगह और क्लाइंट की जगह, इंतज़ार के समय पर असर डाल सकती है.
;; connection timed out; no servers could be reached- खास तौर पर, सिर्फ़ कुछ क्वेरी के लिए, यह एक ऐसी समस्या होती है जहां आपके सर्वर को समय पर डीएनएस क्वेरी का जवाब देने में परेशानी होती है.
आप क्वेरी के ये वर्शन आज़मा सकते हैं:
+tcpपैरामीटर जोड़ना.- ऐसा करने से,
digको तुरंत टीसीपी का इस्तेमाल करना पड़ता है. आपके पास यह देखने का विकल्प होता है कि आपका आधिकारिक सर्वर, टीसीपी क्वेरी को सीधे इस तरीके से मैनेज करता है या नहीं. +bufsize=1400पैरामीटर हटाया जा रहा है.- इससे
digका डिफ़ॉल्ट व्यवहार बहाल हो जाएगा (4096 का बफ़र) अगर आपकी क्वेरी इस सेटिंग के साथ काम नहीं करती हैं, लेकिन इनके बिना काम करती हैं, तो इसका मतलब है कि आपका सर्वर, टीसीपी फ़ेलओवर के साथ ठीक से काम नहीं कर रहा है. बड़े रिस्पॉन्स देने के लिए यूडीपी पर निर्भर रहना सिर्फ़ कभी-कभी काम करता है. इस काम के लिए सबसे सही तरीका है, डीएनएस के लिए टीसीपी ट्रांसपोर्ट की सुविधा देना. - हर नेम सर्वर पर दोहराया जाएगा.
- ऊपर दिए गए उदाहरण में दो आधिकारिक नाम सर्वर (
ns1औरns2) हैं. कुछ सर्वर की वजह से अलग-अलग जवाब मिलते हैं. जांच लें कि वे सभी आधिकारिक सर्वर पर एक जैसी क्वेरी को बार-बार बदलते हैं.
अगर सभी क्वेरी' जवाब छोटे थे (1400 बाइट या उससे कम), तेज़ (काम के 500 मिलीसेकंड या इससे ज़्यादा तेज़) और भरोसेमंद (टीसीपी और यूडीपी के साथ लगातार काम करने पर), तो जवाब का साइज़ आपकी चिंता नहीं है; समस्या हल करने के दूसरे सेक्शन पढ़ें. भले ही आपके जवाब तेज़ हों, लेकिन भौगोलिक रूप से दूर मौजूद क्वेरी की रफ़्तार धीमी हो सकती है.
अगर इनमें से कोई भी जांच पूरी नहीं हो सकी (बड़ा? धीमा? भरोसेमंद नहीं है) डीएनएस की भरोसेमंद समस्याओं से जुड़ी समस्याओं का पता लगाने में कई टूल आपकी मदद कर सकते हैं:
- डीएनएसवीज़
- डीएनएसएसईसी डीबगर
- EDNS की जांच करने वाला टेस्टर
- डीएनएस चेकर -- पक्का करें कि आप "CD"
अगर इन टूल से किसी गड़बड़ी या चेतावनी का पता चलता है, तो उन्हें ठीक ज़रूर करें. साथ ही, इस साइट पर समस्या हल करने के दूसरे सभी निर्देश ज़रूर पढ़ लें.
पांचवां चरण: देखें कि अन्य सार्वजनिक रिज़ॉल्वर डोमेन का समाधान करते हैं या नहीं
अगर ऊपर बताया गया तरीका अपनाने के बाद भी आपको समस्या की कोई वजह नहीं मिलती, तो नीचे दिए गए कमांड कमांड कमांड की मदद से example.test. को बदलें. साथ ही, उस डोमेन को हटाने के लिए ऊपर दिए गए निर्देश का इस्तेमाल करें (और पीछे लगने वाले डॉट को सुरक्षित रखें):
Windows
nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.
macOS या Linux
dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'
ये कमांड, OpenDNS, Quad9, और Cloudflare 1.1.1.1 के डीएनएस रिज़ॉल्वर का इस्तेमाल करते हैं. अगर आपको इनमें से किसी एक समस्या के साथ-साथ Google की सार्वजनिक डीएनएस सेवा के ज़रिए भी कोई गड़बड़ी मिलती है, तो समस्या शायद डोमेन या उसके नाम सर्वर के साथ है.
अगर आपको एक से ज़्यादा सार्वजनिक रिज़ॉल्वर से सफल नतीजा मिलता है, तो Google सार्वजनिक डीएनएस में कोई समस्या हो सकती है. अगर डोमेन से जुड़ी कोई समस्या (या इसके टीएलडी) को समस्या ट्रैकर में रिपोर्ट नहीं किया गया है, तो आपको अपनी समस्या में समस्या की शिकायत करनी चाहिए. इसमें, कमांड आउटपुट और गड़बड़ी की जानकारी वाले पेज का टेक्स्ट या स्क्रीनशॉट शामिल हैं.