nslookup कहता है सर्वर अज्ञात है: यह सिर्फ़ एक लेबल है
रिज़ॉल्वर का अपना रिवर्स नाम और असफल फ़ॉरवर्ड लुकअप अलग नतीजे हैं। VPN DNS सेटिंग बदलने से पहले उत्तर वाला भाग पढ़ें।
VPN से जुड़ें, nslookup चलाएँ, और हेडर में रिज़ॉल्वर का पता नाम वाले खाने में Unknown भरा हुआ दिखेगा। वह शब्द उत्तर के ऊपर बैठता है, और ज़्यादातर लोग अहम हिस्से से पहले पढ़ना छोड़ देते हैं। लेबल बताता है कि रिज़ॉल्वर का अपना रिवर्स नाम है या नहीं; यह अभी यह नहीं कहता कि आपने जो होस्टनेम पूछा वह हल हुआ या नहीं। उस खिड़की को जल्दी बंद करना ही यहाँ पूरी कुशलता है।
दो अलग क्वेरी इस दृश्य को पैदा कर सकती हैं, और उनमें से सिर्फ़ एक आपकी समस्या के बारे में है। उन्हें अलग करने में एक अतिरिक्त कमांड लगता है और उन DNS सेटिंग्स को संपादित करने वाली एक दोपहर बचती है जो कभी ग़लत नहीं थीं।
उत्तर देने से पहले टूल क्या करता है
nslookup उस सर्वर पते के लिए नाम खोजने की कोशिश कर सकता है जिसका वह अभी उपयोग करने वाला है, जो in-addr.arpa या ip6.arpa डोमेन में रिवर्स लुकअप है। अगर वह PTR रिकॉर्ड अनुपस्थित हो, नीति से फ़िल्टर हो या सिर्फ़ प्रकाशित न हुआ हो, तो टूल Unknown छापता है और आगे बढ़ जाता है। फ़ॉरवर्ड रिज़ॉल्यूशन उस विफलता से अछूता रहता है, क्योंकि वह उसी सर्वर को भेजा गया अलग सवाल है।
इसलिए एक निजी रिज़ॉल्वर हर कॉर्पोरेट नाम का सही उत्तर दे सकता है और फिर भी टूल के हेडर में गुमनाम दिख सकता है। पता ज्ञात है; उसके पीछे का नाम नहीं, और टूल इस बारे में ईमानदार है, हालाँकि अपने चुने हुए शब्द को लेकर थोड़ा नाटकीय बना रहता है।
दोनों क्वेरी जानबूझकर चलाएँ
किसी ऐसे होस्ट के बारे में पूछें जो आपके लिए मायने रखता है, फिर रिज़ॉल्वर के अपने पते के बारे में पूछें। पहला अनुरोध वह नाम ले जाता है जिसकी आपको ज़रूरत है; दूसरा सर्वर से पूछता है कि क्या वह खुद को नाम दे सकता है। लिखे जाने पर वे ऐसे दिखते हैं: होस्ट के लिए nslookup app.corp.example 10.77.0.53, और रिज़ॉल्वर के रिवर्स नाम के लिए nslookup 10.77.0.53 10.77.0.53।
दोनों उदाहरण सिर्फ़ दृष्टांत हैं, इसलिए अपने नाम और पते डालें। बात सटीक सिंटैक्स की नहीं, अलगाव की है: दोनों कमांड अलग सवाल पूछते हैं और बिना किसी खराबी के अलग नतीजे दे सकते हैं।
तीन नतीजे जो एक जैसे दिखते हैं और हैं नहीं
समय-समाप्ति का मतलब है कि कोई उत्तर ही नहीं आया, जो पहुँच, फ़िल्टरिंग या ग़लत सर्वर पते की ओर इशारा करता है। नकारात्मक उत्तर का मतलब है कि सर्वर ने जवाब दिया और कहा कि नाम मौजूद नहीं है, जो ज़ोन या प्रत्यय की ओर इशारा करता है। रिवर्स नाम गायब होने का मतलब है कि सर्वर ने दूसरे सवाल का जवाब किसी उपयोगी चीज़ के बिना दिया, और फ़ॉरवर्ड उत्तर फिर भी उत्तम रहा हो सकता है। तीन नतीजे, तीन मालिक, और उनमें से सिर्फ़ एक उस होस्टनेम के बारे में है जिसकी आपको ज़रूरत थी।
सिर्फ़ पहले दो आपके एप्लिकेशन के लिए विफल हो रहे DNS मार्ग का वर्णन करते हैं। तीसरा ऐसे रिकॉर्ड का वर्णन करता है जो कभी प्रकाशित नहीं हुआ, और उसे खराबी मानने से ऐसे बदलाव होते हैं जो उसे ठीक नहीं कर सकते, जैसे हेडर ज़्यादा दोस्ताना दिखे तक खोज प्रत्यय को फिर से लिखना।
भाग पढ़ें, हेडर नहीं
हेडर के नीचे टूल उत्तर, प्राधिकार और कोई भी अतिरिक्त रिकॉर्ड छापता है। उत्तर वाले भाग में सही पता वही नतीजा है जो आप चाहते थे, तब भी जब हेडर का नाम Unknown हो। प्राधिकृत अस्वीकृति के साथ खाली उत्तर अलग परिणाम है और अपनी अलग जाँच का हक़दार है।
सपोर्ट को भेजी हर चीज़ में दोनों चीज़ें स्पष्ट रखें: कौन-सा नाम पूछा गया, और किस सर्वर से पूछा गया। जो रिपोर्ट सिर्फ़ यह बताती है कि VPN पर DNS टूटा है, वह अगले व्यक्ति को वह परीक्षण दोबारा बनाने पर मजबूर करती है जो आप पहले ही कर चुके हैं।
जब रिवर्स नाम वाक़ई मायने रखता है
कुछ सेवाएँ PTR रिकॉर्ड की सचमुच परवाह करती हैं: क्लाइंट पते हल करने वाला लॉगिंग, मेल प्रतिष्ठा जाँच, या नाम दिखाने वाले प्रशासनिक टूल। अगर इनमें से कोई विफल हो, तो रिकॉर्ड प्रकाशित करें या उस ज़ोन को ठीक करें जिसमें वह होना चाहिए। वह काम वैध है और इस सवाल से अलग है कि VPN क्वेरी सही ढंग से आगे भेजता है या नहीं।
सीमित बात टिकी रहती है: एक गायब रिज़ॉल्वर लेबल यह साबित नहीं करता कि सुरंग के ज़रिए फ़ॉरवर्ड रिज़ॉल्यूशन टूटा है, और एक काम करता फ़ॉरवर्ड लुकअप यह साबित नहीं करता कि ज़ोन का हर नाम हल होता है। जिस नाम की आपको सचमुच ज़रूरत है उसे जाँचें, फिर तय करें कि हेडर के शब्द की क्या कीमत है।