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 सेटिंग ते कधीही देऊ शकले नसते.

स्वीकारार्हता ओळ उद्दिष्टाच्या भाषेत लिहा: हे शोध या अटींमध्ये हा पडताळलेला रिझॉल्व्हर वापरतात. यापेक्षा व्यापक काहीही हा असा दावा आहे जो तुम्ही तपासू शकत नाही.