आपका VPN तीन DNS सर्वर भेजता है: कौन उत्तर देता है?
अतिरिक्त प्रविष्टियाँ फ़ॉलबैक, प्रति-डोमेन रूट या भौतिक लिंक का अवशेष हो सकती हैं। सूची को लीक कहने से पहले हर एक को एक दायरे से जोड़ें।
कनेक्ट करने के बाद सेटिंग्स पृष्ठ खोलें और तीन DNS पते सूचीबद्ध दिखेंगे; ऑडिट का प्रश्न यह है कि आपकी पिछली क्वेरी किसने संभाली। केवल संख्या किसी भी बात का उत्तर नहीं देती, क्योंकि क्लाइंट पुश, एक भौतिक इंटरफ़ेस और प्रति-डोमेन नीति सभी एक ही दृश्य में लिखते हैं। इन प्रविष्टियों के भिन्न दायरे हैं, और उत्तर कौन देगा यह स्थिति नहीं, दायरा तय करता है। स्रोतों को अलग करके शुरू करें, फिर उस स्रोत को जाँचें जिसके पास वह नाम है जो आपके लिए मायने रखता है।
सूची आपकी प्रोफ़ाइल से लंबी क्यों है
एक VPN क्लाइंट टनल लिंक के लिए रिज़ॉल्वर पते भेजता है, और ऑपरेटिंग सिस्टम उन्हें भौतिक इंटरफ़ेस के पास पहले से जो था उसके साथ रखता है। राउटर, कॉर्पोरेट DHCP लीज़, दूसरा VPN और प्रति-डोमेन नीति में से हर एक अपनी प्रविष्टि जोड़ता है। इसलिए पृष्ठ पर तीन पते एक काम के लिए तीन उम्मीदवार नहीं, बल्कि तीन दायरे हो सकते हैं। संख्या को लीक का प्रमाण पढ़ना इस ऑडिट की पहली गलती है।
एक इंटरफ़ेस के भीतर क्लाइंट वास्तव में अपने सर्वरों को क्रम से आज़माता है, इसलिए क्रमबद्ध सूची अर्थहीन नहीं है। जो कतार नहीं है वह मिलाजुला दृश्य है, जहाँ प्रोफ़ाइल, भौतिक लिंक और प्रति-डोमेन नियमों की प्रविष्टियाँ बिना किसी एकल क्रम के साथ-साथ बैठती हैं। यही भेद तय करता है कि आप क्या जाँचेंगे: क्रम एक दायरे के भीतर व्यवहार समझाता है, और दायरा बाकी सब कुछ।
एन्क्रिप्टेड DNS चित्र को एक एप्लिकेशन के भीतर से तोड़ता है। अपना DNS-over-HTTPS रिज़ॉल्वर रखने वाला ब्राउज़र या चैट क्लाइंट क्वेरी ऑपरेटिंग सिस्टम की सूची को पूरी तरह से बायपास करके भेजता है, इसलिए सेटिंग्स पृष्ठ के पते ऐसे ट्रैफ़िक का वर्णन करते हैं जो ऐप ने कभी उत्पन्न नहीं किया। नाम गलत आने के लिए प्रोफ़ाइल को दोष देने से पहले ऐप की अपनी रिज़ॉल्वर सेटिंग जाँचें।
तीन जाँचों में से हर एक क्या बताती है
हर स्रोत अपनी छाप अलग जगह छोड़ता है, और कोई एक कमांड सबको नहीं दिखाती। यह वह मैपिंग है जिसे सेटिंग्स पृष्ठ के पास रखना उचित है:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved का उपयोग करने वाले सिस्टम पर resolvectl status प्रामाणिक है, क्योंकि यह रूटिंग डोमेन के साथ प्रति-लिंक DNS की रिपोर्ट करती है। macOS scutil --dns के माध्यम से उत्तर देता है, जो दायरे वाले रिज़ॉल्वरों को आज़माने के क्रम में सूचीबद्ध करता है। Windows दो हिस्सों में बाँटता है: प्रति-इंटरफ़ेस सर्वरों के लिए Get-DnsClientServerAddress और सफ़िक्स नियमों के लिए Get-DnsClientNrptPolicy। वह कमांड चलाएँ जो वास्तव में उपयोग हो रहे रिज़ॉल्वर की हो, क्योंकि कंटेनर रनटाइम और डेस्कटॉप रिज़ॉल्वर वाली मशीन में एक से अधिक स्थापित हो सकते हैं।
दूसरा बैकअप रिज़ॉल्वर जो आपके ज़ोन का उत्तर नहीं दे सकता
दूसरी प्रविष्टि आमतौर पर उपलब्धता के लिए होती है, और उपलब्धता तभी काम करती है जब बैकअप नामों को जानता हो। किसी सार्वजनिक रिज़ॉल्वर से आंतरिक होस्टनाम पूछें तो वह NXDOMAIN लौटाता है, या आपसे कोई संबंध न रखने वाले सर्च डोमेन से वाइल्डकार्ड उत्तर देता है। फिर कोई भी न जाँचा गया फ़ेलओवर ठीक उसी क्षण आउटेज पैदा करता है जब उसकी ज़रूरत होती है।
Split DNS इसी को रोकने के लिए है: कंपनी के सफ़िक्स ज़ोन रखने वाले रिज़ॉल्वर पर जाते हैं, और सार्वजनिक नाम डिफ़ॉल्ट पथ पर रहते हैं। डिज़ाइन ठोस है, और यह सफ़िक्स सूची के पूर्ण होने पर निर्भर करता है। Microsoft प्रति-सफ़िक्स रिज़ॉल्वर नीति का दस्तावेज़ीकरण करता है जो Windows पर इसे चलाती है, और वही विचार systemd-resolved में रूटिंग डोमेन और macOS पर दायरे वाले रिज़ॉल्वर के रूप में दिखता है।
बैकअप जिन ज़ोन का उत्तर दे सकता है, उनकी नीति में मौजूद सफ़िक्स से तुलना करें। यह तुलना उपयोगकर्ता के यह बताने से पहले ही अंतराल खोज लेती है कि टनल बदलाव के बाद एक आंतरिक साइट हल होना बंद हो गई।
ऑपरेटिंग सिस्टम के रिज़ॉल्वर से पूछें, उसके इर्द-गिर्द नहीं
ऑपरेटिंग सिस्टम के रिज़ॉल्वर के माध्यम से पूछें, क्योंकि सर्वर से सीधी क्वेरी नीति को बायपास करती है और केवल वही बताती है जो वह सर्वर कहता होगा। दो उत्तरों के बीच का अंतर ही पूरी बात है:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53यदि सिस्टम क्वेरी निजी पता लौटाती है जबकि सीधी क्वेरी NXDOMAIN लौटाती है, तो नीति काम कर रही है और बैकअप कमज़ोर बिंदु है। यदि दोनों एक ही सार्वजनिक उत्तर लौटाते हैं, तो नाम आपके इच्छित दायरे के बाहर हल हो रहा है, और सफ़िक्स सूची देखने की जगह है। दोनों आउटपुट रखें, क्योंकि सेटिंग्स पृष्ठ के स्क्रीनशॉट की तुलना में रिज़ॉल्वर बहस दो पंक्तियों से जल्दी सुलझती है।
फिर विफलता पथ का अभ्यास करें, क्योंकि जिस फ़ॉलबैक को किसी ने जाँचा नहीं वह एक अनुमान है। एक क्वेरी के लिए पसंदीदा रिज़ॉल्वर को ब्लैकहोल बनाएँ और देखें कौन सा पता लौटता है:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32क्वेरी पूरी होते ही वह रूट हटा दें, अन्यथा अगला व्यक्ति एक रहस्य विरासत में पाता है। यदि उस अवधि में आंतरिक नाम अब भी हल होते हैं, तो इच्छित दायरे के बाहर किसी चीज़ ने उनका उत्तर दिया। यदि वे इसके बजाय समय समाप्त हो जाते हैं, तो फ़ॉलबैक अनुपस्थित है या ठीक से सीमित है, और रिज़ॉल्वर का अपना लॉग बताता है कि दोनों में से कौन सा था।
तय करें: रखें, सीमित करें या हटाएँ
दूसरा रिज़ॉल्वर तब रखें जब वह आपके ज़रूरी नामस्थान का उत्तर दे और प्रोफ़ाइल के अंतर्गत पहुँचने योग्य रहे। उसे तब सीमित करें जब उसे केवल एक सफ़िक्स और कुछ नहीं देखना चाहिए, और उसे हटा दें जब उसका न दायरा हो न प्रलेखित उद्देश्य। बिना काम की प्रविष्टि बिना लाभ का भावी लीक है, और विक्रेता का डिफ़ॉल्ट उद्देश्य नहीं है।
परिणाम को चार कॉलमों में दर्ज करें: सफ़िक्स, रिज़ॉल्वर, इंटरफ़ेस और मालिक। वह पंक्ति किसी भी स्क्रीनशॉट से जल्दी अगले ऑडिट प्रश्न का उत्तर देती है, और सूची को चुपचाप पुनर्व्यवस्थित करने वाले क्लाइंट अपडेट से भी बची रहती है।