VPN के बिना एन्क्रिप्टेड DNS क्वेरी छिपाता है, आपका पता नहीं

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

कोई भी परीक्षण चलाने से पहले लक्ष्य लिख लें।

चरण 1: उस सुरक्षा का नाम दें जो आप वास्तव में चाहते हैं

तीन लक्ष्य आपस में मिल जाते हैं। हो सकता है आप चाहें कि रास्ते पर मौजूद कोई पर्यवेक्षक क्वेरी पढ़ना बंद कर दे। हो सकता है आप चाहें कि कोई विशेष रिज़ॉल्वर उन्हें प्राप्त करना बंद कर दे। हो सकता है आप चाहें कि आप जिन वेबसाइटों पर जाते हैं वे आपका घरेलू पता देखना बंद कर दें. एन्क्रिप्टेड DNS पहले की सेवा करता है, बदलता है कि दूसरा कौन पूरा करता है, और तीसरे के लिए कुछ भी नहीं करता।

VPN तीसरे की सेवा करता है और प्रदाता के आधार पर पहले की भी। दोनों में से कोई उपकरण दूसरे का सुपरसेट नहीं है।

चरण 2: एक रिज़ॉल्वर चुनें और उसकी पहचान सत्यापित करें

DNS over TLS क्वेरी को रिज़ॉल्वर के साथ TLS सत्र में लपेटता है, और DNS over HTTPS उसे HTTP अनुरोध में लपेटता है; RFC 7858 और RFC 8484 दोनों का वर्णन करते हैं, और किसी को भी सुरंग की आवश्यकता नहीं है। परिचालन रूप से महत्वपूर्ण यह है कि प्रमाणपत्र उस नाम के विरुद्ध सत्यापित हो जो आपने कॉन्फ़िगर किया, क्योंकि गलत पक्ष के साथ एन्क्रिप्टेड सत्र सही पक्ष के साथ सादे पाठ से बुरा है। इसका अर्थ है कठोर मोड जहाँ प्लेटफ़ॉर्म इसे प्रदान करता है, न कि अवसरवादी मोड जो सत्यापन विफल होने पर पीछे हट जाता है। सेटिंग पर भरोसा करने से पहले सत्र को सीधे जाँचें: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

हैंडशेक में आपके द्वारा कॉन्फ़िगर किए गए रिज़ॉल्वर का नाम होना चाहिए और ऐसी श्रृंखला लौटनी चाहिए जिसे आप सत्यापित कर सकें।

चरण 3: विफलता के व्यवहार का निर्णय करें

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

systemd-resolved पर अवसरवादी मोड नहीं, DNSOverTLS=yes चुनना चाहिए; दूसरा मान, opportunistic; और Android पर इसका अर्थ है स्वचालित के बजाय Private DNS होस्टनाम मोड।

वास्तव में क्या लागू है, यह इससे जाँचें: resolvectl status | grep -i -A1 "dns over tls", क्योंकि कभी पुनः लोड न की गई drop-in फ़ाइल कुछ नहीं बदलती।

चरण 4: जाँचें कि अनुप्रयोग सिस्टम रिज़ॉल्वर का पालन करते हैं

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

संगठन के निजी नाम स्वीकृत आंतरिक रिज़ॉल्वर पर ही रहते हैं। परीक्षण सुंदर दिखे इसके लिए उन्हें सार्वजनिक सेवा पर भेजना जानबूझकर एक अलग समस्या पैदा करता है।

चरण 5: आवश्यकता के विरुद्ध लीक परीक्षण पढ़ें

अप्रत्याशित रिज़ॉल्वर की रिपोर्ट करने वाला परीक्षण संकेत है, फैसला नहीं. हो सकता है उसने आपके इच्छित एन्क्रिप्टेड रिज़ॉल्वर, किसी ऐप-विशिष्ट सेटिंग, या सादे पाठ में ऐसी वापसी देखी हो जिसके बारे में आप नहीं जानते थे। रिपोर्ट किए गए रिज़ॉल्वर की तुलना चरण 2 में कॉन्फ़िगर किए गए से करें, और परिणाम की तुलना चरण 1 के लक्ष्य से करें।

यदि लक्ष्य क्वेरी को स्थानीय नेटवर्क से दूर रखना था, तो आपका सामान्य रिज़ॉल्वर दिखाने वाला परीक्षण वास्तविक खोज है। यदि लक्ष्य ब्राउज़िंग के दौरान अनामता था, तो कोई भी DNS सेटिंग उसे कभी नहीं देती।

स्वीकृति पंक्ति लक्ष्य की भाषा में लिखें: ये खोजें इन शर्तों के तहत इस सत्यापित रिज़ॉल्वर का उपयोग करती हैं। इससे व्यापक कुछ भी ऐसा दावा है जिसे आप परख नहीं सकते।