Split-DNS कैप्चर: बताइए हर अवलोकन कहाँ लिया गया

दो लोग एक ही Split-DNS समस्या का निदान करते हैं और अलग-अलग resolver पते पाते हैं। एक ने लुकअप उपकरण इस्तेमाल किया, दूसरे ने एडाप्टर पर पैकेट कैप्चर किए, और तीसरे ने क्लाइंट के अपने डायग्नोस्टिक्स पढ़े। इनमें से कोई झूठ नहीं बोल रहा, और कोई एक ही चरण का वर्णन नहीं कर रहा। अवलोकन-बिंदु का नाम लेने से विरोधाभास एक नक्शे में बदल जाता है।

एक लुकअप, कई अवलोकन-बिंदु

एक भीतरी नाम के लिए देखने की कम से कम पाँच जगहें हैं: एप्लिकेशन और उसका बुलाया जाने वाला resolver API, क्लाइंट पर प्रभावी डोमेन नीति, एडाप्टर या फ़िल्टर पर कैप्चर, नियंत्रित गेटवे सीमा, और वह resolver जो वास्तव में क्वेरी प्राप्त करता है।

हर एक अलग सवाल का जवाब देता है, और कोई भी अकेले यह सिद्ध नहीं करता कि क्वेरी कहाँ गई।

एडाप्टर पर कैप्चर पैकेट दिखाता है, मंशा नहीं। यह नहीं बताता कि क्लाइंट ने कौन-सा resolver चुना, और खाली कैप्चर कैश किया गया जवाब या कोई दूसरा resolver API हो सकता है, गिराया गया पैकेट नहीं। हर अवलोकन को एक चरण का साक्ष्य मानिए। फिर चरणों को एक पथ में जोड़िए।

क्लाइंट का फ़िल्टर ऐप और तार के बीच बैठता है

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

Cisco का Secure Client Split-DNS मार्गदर्शन डोमेन मिलान और Windows फ़िल्टर को कवर करता है, और यह अलग करता है कि ऐप मूल resolver API इस्तेमाल करते समय क्या देखता है और nslookup जैसा उपकरण क्या देखता है। यही अंतर मुख्य बात है।

प्रभावी प्रोफ़ाइल और एक साधारण एप्लिकेशन लुकअप से शुरू करें। किसी स्पष्ट सर्वर का नाम लेने वाला हर परीक्षण जानबूझकर किया गया चक्कर है; इसे समझाने के लिए क्लाइंट के अपने डायग्नोस्टिक्स इस्तेमाल करें, और इसे स्वीकृति-मानदंड बनने न दें।

nslookup ऐप से अलग रास्ता लेता है

nslookup अपनी खुद की DNS क्वेरी बनाता है और ऑपरेटिंग सिस्टम की resolver नीति को बायपास कर सकता है। यह उसे किसी विशेष सर्वर से कोई विशेष सवाल पूछने के लिए उपयोगी उपकरण बनाता है, और यह जाँचने के लिए भ्रामक उपकरण कि एप्लिकेशन क्या अनुभव करेगा।

Windows में नाम-रिज़ॉल्यूशन नीति तालिका तय करती है कि कौन-सा सफ़िक्स किस सर्वर का उपयोग करे। इसे पढ़ने से वह नीति दिखती है जिसका एप्लिकेशन पालन करेगा, और अक्सर वही छूटा हुआ टुकड़ा होता है।

नीति पढ़िए और फिर वही सवाल सामान्य resolver से पूछिए:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

एन्क्रिप्टेड resolver क्वेरी छिपाते हैं, कनेक्शन नहीं

अपना DNS-over-HTTPS resolver रखने वाला ब्राउज़र बिल्कुल अलग मामला है। क्वेरी TLS के भीतर निकलती है, इसलिए पैकेट कैप्चर resolver पते से कनेक्शन दिखाता है, पर पूछा गया नाम नहीं दिखाता।

पहले ब्राउज़र की प्रबंधित नीति पता कीजिए, फिर उसकी तुलना ऑपरेटिंग सिस्टम के लुकअप से कीजिए। अपना resolver चुनने की अनुमति वाला ब्राउज़र Split-DNS नीति शायद ही कभी देखे।

यही सावधानी उस हर क्लाइंट पर लागू होती है जो अपना resolver लाता है। दूर के कनेक्शन को पहचानने वाला कैप्चर क्वेरी के नाम का साक्ष्य नहीं है। अगर नाम चाहिए, तो उसे resolver के अपने लॉग या एप्लिकेशन के डायग्नोस्टिक्स से लें, लागू गोपनीयता नियमों के साथ।

लेबल वाले परीक्षण से तुलना कीजिए

परीक्षण के लिए एक स्वीकृत भीतरी नाम चुनिए, साथ में ऐसा सार्वजनिक नाम जिसका कोई संवेदनशील अर्थ न हो। हर एक के लिए समय, रिकॉर्ड प्रकार, जवाब और अपेक्षित नीति दर्ज कीजिए।

जहाँ अनुमति हो, resolver की प्राप्ति की तुलना एक सँकरे क्लाइंट या गेटवे अवलोकन से कीजिए:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

सिर्फ़ तुलना बनाने के लिए निजी नाम असंबंधित सार्वजनिक resolver को कभी न भेजिए, और जो भी साझा करें उसे संपादित कीजिए। अंत में, सही DNS जवाब को उसके बाद आने वाले सेवा-कनेक्शन से अलग कीजिए: हल किए गए निजी पते को अभी भी मार्ग और एप्लिकेशन अनुमति चाहिए।