TLS माथिको DNS र VPN: कुन भाग सुरक्षित छ

TLS माथिको DNS ले क्लाइन्ट र उसले छानेको resolver बीचको आदानप्रदान इन्क्रिप्ट गर्छ, र resolver ले अझै नाम पढ्छ। यो वाक्यले DoT र VPN वरपरको धेरैजसो अन्योल टुङ्गोमा पुर्‍याउँछ। इन्क्रिप्टेड क्वेरी कुन बाटो जान्छ भन्ने सुरुङले निर्धारण गर्छ, जबकि resolver ले के सोधियो भन्ने थाहा पाउँछ। कुनै पनि संयन्त्रले अर्कोलाई प्रतिस्थापन गर्दैन, र कुनैले पनि अर्कोलाई अनावश्यक बनाउँदैन।

तपाईंसँग भएको व्यवस्था तपाईंले सोचेको जस्तै हो कि होइन भन्ने चार जाँचले निर्धारण गर्छ।

जाँच 1: इन्क्रिप्शनले के ढाक्छ

DoT ले DNS आदानप्रदानलाई TLS मा बेर्छ, त्यसैले मार्गमा रहेको पर्यवेक्षकले क्वेरीभित्रको नामको सट्टा ठेगाना र पोर्टसँगको जडान देख्छ। resolver आफैं डिक्रिप्ट गरेर जवाफ दिन्छ। यसलाई HTTPS माथिको DNS सँग तुलना गर्नुहोस्: दुवै इन्क्रिप्ट गर्छन्, र तिनीहरू फरक फरक ट्रान्सपोर्ट प्रयोग गर्छन्, त्यसैले वेब ट्राफिकलाई अनुमति दिने नेटवर्कले DoT जडानलाई स्वतः अनुमति दिँदैन।

क्याप्टिभ पोर्टल वा फिल्टर गर्ने बीचको बाकसले 443 लाई अनुमति दिएर 853 रोक्दा यो भिन्नता महत्त्वपूर्ण हुन्छ। त्यहाँ चलेको उपकरण अर्को पनि चल्ने प्रमाण होइन।

जाँच 2: क्वेरी कुन मार्गबाट जान्छ

मार्ग क्लाइन्ट नीतिको प्रश्न हो। DoT resolver सम्म सुरुङबाट, त्यसको बाहिरबाट, वा नेटवर्कसँगै बदलिने बाटोबाट पुग्न सकिन्छ। कुन हुन्छ भन्ने मार्गहरूमा र क्लाइन्टले आफ्नै DNS सकेट सुरक्षित राख्छ कि राख्दैन भन्नेमा निर्भर गर्छ। सबै ट्राफिक समात्ने सुरुङले सामान्यतया क्वेरी पनि साथै लैजान्छ, resolver को ठेगानाले जे भने पनि।

परीक्षणमा तेस्रो पक्षको resolver ठेगाना देख्नु बाइपास प्रमाणित गर्दैन, र इन्क्रिप्शन देख्नुले अभिप्रेत प्राप्तकर्ता प्रमाणित गर्दैन। resolver र मार्ग अलग अलग पढ्नुहोस्, त्यसपछि जोडी तपाईंले डिजाइन गरेको नै हो कि भनेर निर्णय गर्नुहोस्।

जाँच 3: आन्तरिक नामहरू

आन्तरिक नाम प्रकाशित गर्ने संस्थालाई ती रेकर्ड राख्ने resolver चाहिन्छ। सार्वजनिक DoT सेवाले तपाईंको निजी नाम-स्थान जान्दैन, र क्लाइन्टलाई त्यसमा फर्काउँदा ती नामहरू असफल हुने निश्चित हुन्छ। व्यवस्थापित उपकरणमा कसैले इन्क्रिप्टेड DNS सक्रिय गर्दा हुने सबैभन्दा सामान्य व्यावहारिक गिरावट यही हो।

आन्तरिक प्रत्ययका लागि आन्तरिक resolver राख्नुहोस् र नीतिले मागेमा त्यो फड्को इन्क्रिप्ट गर्नुहोस्, यसलाई सार्वजनिक प्रदायकले प्रतिस्थापन गर्नुको सट्टा।

जाँच 4: असफलताको व्यवहार

पुग्न सकिने resolver बिनाको कडा resolver सेटिङले सुरुङ माथि रहँदा नै नाम-समाधान असफलता उत्पन्न गर्छ। कुञ्जी वा प्रमाणपत्र छुनुको सट्टा प्लेटफर्म मोड र त्यसको अभिलेखित फलब्याक हेर्नुहोस्।

चुपचाप साधारण DNS प्रयोग गर्ने फलब्याक नीतिको निर्णय हो, सुविधा होइन। असफलता देखिनुपर्छ कि अझ कमजोर कुनै कुरामा झर्नुपर्छ भनेर निर्णय गर्नुहोस्, र जवाफ लेख्नुहोस्।

प्रमाणपत्रमा विश्वास गर्नुहोस्, जवाफमा होइन

सेवाका लागि अभिलेखित प्रदायकको होस्टनाम र प्रमाणीकरण कन्फिगरेसन प्रयोग गर्नुहोस्। अपरिचित resolver जवाफ दियोस् भनेर TLS जाँच बन्द गर्नाले तपाईंलाई अप्रमाणित अन्त्यबिन्दुसम्म इन्क्रिप्टेड च्यानल दिन्छ, जुन प्रतिस्थापित साधारण क्वेरीभन्दा एक विशेष हिसाबले नराम्रो छ: यो सुरक्षित देखिन्छ। DNS over TLS विशिष्टता ले त्यो जाँचपछाडिको प्रमाणीकरण अपेक्षा प्रस्तुत गर्छ।

तपाईंले प्रमाणित गर्न नसक्ने resolver को जवाफ दाबी हो, नतिजा होइन।

यसले के अस्पष्ट छोड्छ

DoT ले नाम resolver बाट लुकाउँदैन, जडानको गन्तव्य ठेगाना नेटवर्कबाट लुकाउँदैन, र क्वेरी सुरुङबाट गयो कि गएन भन्ने निर्धारण गर्दैन। ती तीन अलग प्रश्न र तीन अलग जवाफ हुन्।

resolver पहिचान, ट्रान्जिट मार्ग र आन्तरिक-नाम नीति तीन लाइनका रूपमा लेख्नुहोस्। अर्को पाउने DNS प्रश्न तीमध्ये एक हुनेछ।