सार्वजनिक DNS का काम करना यह नहीं दिखाता कि Active Directory मिल सकता है

VPN जुड़ता है, ब्राउज़र एक सार्वजनिक साइट खोलता है, और लैपटॉप फिर भी डोमेन में साइन-इन नहीं कर पाता। सामान्य निष्कर्ष यह होता है कि DNS ठीक है क्योंकि नाम हल हो रहे हैं। यह ठीक नहीं है, और कारण यह है कि ब्राउज़र परीक्षण उस श्रृंखला में से केवल एक लुकअप आज़माता है जो डोमेन से जुड़े क्लाइंट को चाहिए। डोमेन खोज पहले सेवा रिकॉर्ड मांगती है, फिर उन रिकॉर्ड में नामित कंट्रोलरों के पते, और फिर उन कंट्रोलरों के उन पोर्टों तक रूट जिन पर वे सुनते हैं। सार्वजनिक उत्तर इनमें से कोई भी चरण पूरा नहीं करता।

भ्रम: नाम हल होते हैं, इसलिए DNS पूरा है

सार्वजनिक साइट का हल होना केवल यह बताता है कि किसी रिज़ॉल्वर ने सार्वजनिक ज़ोन के एक नाम के लिए एक A या AAAA क्वेरी का उत्तर दिया। Active Directory उसी प्रोटोकॉल का प्रयोग दूसरे प्रश्न के लिए करता है: डोमेन की सेवाएँ कहाँ हैं, और इस क्लाइंट को कौन-सा कंट्रोलर इस्तेमाल करना चाहिए। प्रश्न डोमेन के नाम वाले ज़ोन के अंतर्गत SRV रिकॉर्ड के रूप में व्यक्त होता है, और पुनरावर्ती सार्वजनिक रिज़ॉल्वर के पास उन्हें रखने का कोई कारण नहीं है।

रिकॉर्ड न हो तो रिज़ॉल्वर नकारात्मक उत्तर देता है, जो रुकावट नहीं बल्कि मान्य DNS उत्तर है। इसके बाद क्लाइंट कैश में रखी कंट्रोलर जानकारी के पास लौट जाता है, यदि उसके पास हो, और ठीक इसी कारण डेस्कटॉप घंटों ठीक दिख सकता है और रीबूट या पासवर्ड बदलने के बाद विफल हो सकता है।

डोमेन क्लाइंट वास्तव में क्या मांगता है, क्रम में

corp.example जैसे डोमेन के लिए सामान्य लोकेटर क्वेरी _ldap._tcp.dc._msdcs.corp.example है। SRV उत्तर संभावित कंट्रोलरों और उनके पोर्टों के नाम देते हैं, और फिर कनेक्शन खोलने से पहले क्लाइंट को उन होस्ट नामों के लिए पता रिकॉर्ड चाहिए। साइट-सजग खोज साइट सबडोमेन के अंतर्गत क्वेरी जोड़ती है, और उत्तर तय करते हैं कि कौन-से कंट्रोलर पसंदीदा हैं, यह नहीं कि कौन अनिवार्य है।

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

इसी क्रम में श्रृंखला का पालन करें, उस नेटवर्क से जहाँ समस्या होती है। ऐसा होस्ट नाम जो अगम्य पते पर हल हो, रूटिंग विफलता है, DNS विफलता नहीं। पहुँच योग्य कंट्रोलर जिसके लोकेटर रिकॉर्ड गायब हैं, DNS विफलता है, रूटिंग विफलता नहीं। दोनों समान उपयोगकर्ता शिकायतें और पूरी तरह अलग मरम्मत पैदा करते हैं।

सार्वजनिक रिज़ॉल्वर उत्तर क्यों देता है और साइन-इन फिर भी टूटता क्यों है

यदि एडाप्टर क्लाइंट को सार्वजनिक रिज़ॉल्वर देता है, तो सार्वजनिक नाम काम करते हैं और आंतरिक नामस्थान नहीं। दूसरा सार्वजनिक रिज़ॉल्वर जोड़ने से लाभ नहीं होता, क्योंकि दोनों में से कोई ज़ोन नहीं रखता। सामान्य “पहले आंतरिक, फिर सार्वजनिक” सूची भी प्रति-डोमेन नियम की तरह व्यवहार नहीं करती: पहले सर्वर का नकारात्मक उत्तर वैध उत्तर है, और क्लाइंट केवल इसलिए दूसरे सर्वर को दोबारा नहीं आज़माता कि उत्तर खाली था।

दोनों आंतरिक रिज़ॉल्वर, यदि आप दो चलाते हैं, AD नामस्थान रखें और क्लाइंट के वर्तमान नेटवर्क से पहुँच योग्य हों। स्प्लिट-टनल डिज़ाइन यही हिस्सा तोड़ते हैं: VPN टनल सबनेट ले जा सकता है जबकि आंतरिक रिज़ॉल्वर ऐसे प्रीफ़िक्स पर बैठा हो जिसे टनल रूट नहीं करता, इसलिए क्वेरी ऐसे रिज़ॉल्वर तक जाती है जो उसका उत्तर नहीं दे सकता।

Windows नाम हल करने की नीति भी लागू करता है जो विशिष्ट नामस्थानों को विशिष्ट सर्वरों पर भेज सकती है, और एडाप्टर जो DNS पते दिखाता है वे पूरी कहानी नहीं हैं। उस नीति को बदले बिना एडाप्टर सूची बदलने से प्रभावी कॉन्फ़िगरेशन अछूता रह सकता है, और इसीलिए लागू दिखने वाला सुधार कोई प्रभाव नहीं डालता।

टनल के DNS और उसके रूट को मेल में रखें

जो VPN प्रोफ़ाइल रिज़ॉल्वर भेजती है पर उसे समेटने वाला प्रीफ़िक्स नहीं भेजती, वह ऐसा रिज़ॉल्वर बनाती है जिस तक क्लाइंट नहीं पहुँच सकता; जो प्रीफ़िक्स भेजती है पर रिज़ॉल्वर नहीं, वह क्लाइंट को स्थानीय से पूछने पर छोड़ देती है। जोड़ी को एक कॉन्फ़िगरेशन मद मानें और हर प्रोफ़ाइल बदलाव के बाद दोनों जाँचें, क्योंकि पुनर्व्यवस्थित पुश या नई स्प्लिट-टनल नीति उन्हें अलग कर सकती है।

यह भी जाँचें कि क्लाइंट भेजी गई सेटिंग के साथ क्या करता है। कुछ क्लाइंट DNS सर्वर को केवल टनल इंटरफ़ेस पर लागू करते हैं और भौतिक एडाप्टर का रिज़ॉल्वर जहाँ था वहीं छोड़ देते हैं, इसलिए कौन जीतेगा यह इंटरफ़ेस मीट्रिक और पूछे जा रहे नाम पर निर्भर करता है। यदि आंतरिक उत्तर केवल तब आता है जब भौतिक एडाप्टर अक्षम हो, तो सुधारने वाला तंत्र वही है, डोमेन रिकॉर्ड नहीं।

एक खोज कॉल और एक जीवंत क्रिया से स्वीकार करें

उपयोगी स्वीकृति परीक्षण लोकेटर क्वेरी चलाता है और फिर एक वास्तविक प्रमाणित क्रिया करता है, जैसे निर्देशिका-आधारित शेयर खोलना या टिकट मांगना। इसे VPN बदलाव से पहले और बाद में फिर से, उसी मशीन पर, बीच में रीबूट किए बिना करें। कैश किए गए क्रेडेंशियल और पहले से खुले सत्र टूटे रास्ते को खुशी से स्वस्थ दिखा देंगे, इसलिए सफल डेस्कटॉप लॉगिन परीक्षण नहीं है।

Microsoft की DNS क्लाइंट के लिए सिफ़ारिशें आंतरिक नामस्थान हल करने और सार्वजनिक क्वेरी ऊपर की ओर अग्रेषित करने के बीच वही रेखा खींचती हैं, और VPN लागू करते समय यही व्यवस्था बनाए रखनी चाहिए।

यदि विफलता केवल धीमी है, विफल नहीं, तो देरी को निदान से अलग रखें। खोज के दौरान समय-समाप्ति अगम्य कंट्रोलर, अवरुद्ध पोर्ट या देर से उत्तर देने वाले रिज़ॉल्वर से आ सकती है, और इनमें से कोई भी केवल प्रतीक्षा से सिद्ध नहीं होता। रिज़ॉल्वर सेटिंग बदलने से पहले वास्तविक क्वेरी, उसका उत्तर और कनेक्शन का प्रयास दर्ज करें।