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 सेटिङले त्यो कहिल्यै दिँदैनथ्यो।

स्वीकृति रेखा लक्ष्यको भाषामा लेख्नुहोस्: यी खोजहरूले यी सर्तहरूमा यो प्रमाणित रिजोल्भर प्रयोग गर्छन्। यसभन्दा फराकिलो जे पनि तपाईंले परीक्षण गर्न नसक्ने दाबी हो।