1.1.1.1 कसले चलाउँछ? विश्वास गर्नु अघि DNS ठेगाना जाँच्नु
VPN सँग प्रयोग गरिएको DNS ठेगाना त्यही VPN ले चलाउँछ भन्ने छैन। रिजोल्भर पहिचान गर्नुहोस्, त्यसपछि बाटो र निजी नामहरूको नीति छुट्टाछुट्टै जाँच्नुहोस्।
तपाईंले 1.1.1.1 लाई VPN को DNS फिल्डमा टाँस्नुभयो, पृष्ठ लोड भयो, र ट्युटोरियल अब पुष्ट देखिन्छ। त्यो अवलोकन महसुस हुनेभन्दा साँघुरो छ: अनुप्रयोगले फरक व्यवहार गर्यो, र परिवर्तनले अझै क्वेरीको जवाफ कसले दियो वा पुरानो व्यवस्था किन असफल भयो भन्ने बारे केही भन्दैन। प्रतिलिपि गरिएको ट्युटोरियलले परिचित सार्वजनिक ठेगानालाई “VPN को DNS” भन्छ, र त्यो स्वामित्वको दाबी हो, पहुँचको होइन। ठेगानाले के प्रतिनिधित्व गर्छ भनेर जाँच्न पाँच मिनेट लाग्छ र गलत कारणले गरिएको स्थायी परिवर्तन रोकिन्छ।
काम गर्ने सेटिङ पहिचान होइन
सेटिङ फिल्डको ठेगाना एउटा अन्त्यबिन्दु हो, र अन्त्यबिन्दुको एक सञ्चालक हुन्छ। यी दुई तथ्य छुट्टाछुट्टै छन्, र दोस्रो त्यो हो जुन मानिसहरूले छोड्छन्। सबैभन्दा धेरै प्रतिलिपि गरिने जोडीका लागि जवाफ सार्वजनिक छ: Cloudflare ले 1.1.1.1 र 1.0.0.1 लाई आफ्नो रिजोल्भर ठेगानाका रूपमा प्रकाशित गर्छ र तिनीहरूलाई आफ्नो आधिकारिक ठेगाना सन्दर्भमा सूचीबद्ध गर्छ। त्यसैले सञ्चालकको नाम ठेगानाको छेउमा हुन्छ, छुट्टै ट्युटोरियलमा होइन।
टनेल खुला रहँदा त्यो जोडी प्रविष्ट गर्नाले VPN कम्पनीलाई त्यसको सञ्चालक बनाउँदैन, र ट्राफिकलाई अज्ञात बनाउँदैन। क्वेरी तपाईंको मेसिनबाट ठेगाना दायरा प्रकाशित गर्ने कम्पनीतिर जान्छ, र त्यो कम्पनी प्रतिष्ठित हुन सक्छ र तैपनि ट्युटोरियलले संकेत गरेको पक्ष नहुन सक्छ। निर्देशनहरूको लेबल र वास्तविकताको सञ्चालक दुई फरक दाबी हुन्। कुनैले पनि बीचको नेटवर्क बाटो कसले चलाउँछ भन्दैन।
ठेगाना जोडी वा इन्क्रिप्टेड अन्त्यबिन्दु पुष्ट गर्न रिजोल्भरको आफ्नै प्रकाशित सन्दर्भ प्रयोग गर्नुहोस्। अर्को आपूर्तिकर्ताको सिफारिस वैध हुन सक्छ, र “सिफारिस गरिएको”, “मार्फत पुगेको” र “सञ्चालित” अझै तीन फरक सम्बन्ध वर्णन गर्छन्।
रेकर्डलाई चाहिने तीन कुरा तुलना गर्नुहोस्
समीक्षाका लागि तयार रेकर्डले तीन प्रश्न अलग गर्छ: क्वेरी कसले पाउनुपर्छ, आदानप्रदान साधारण हो वा इन्क्रिप्टेड, र कुन बाटोले त्यसलाई बोक्नुपर्छ। आपूर्तिकर्ताको नामले दोस्रो वा तेस्रो भर्न सक्दैन, र देशको लेबलले तीमध्ये कुनै पनि भर्न सक्दैन। परिवर्तन अघि तीन प्रविष्टि लेख्नुहोस् र पछि तिनको तुलना गर्नुहोस्। ती प्रविष्टि अदलबदल गर्न मिल्ने छैनन्, र तिनलाई एक मान्नु नै अनुमान दस्तावेज बन्ने बाटो हो।
तुलनाले नै काम गर्ने सेटिङलाई अभिलेखित निर्णय बनाउँछ। त्यो बिना अर्को व्यक्तिले कुनै कारण नभएको ठेगाना उत्तराधिकारमा पाउँछ। तलको तालिकाको तेस्रो स्तम्भ पहिले पढ्नुहोस्, किनकि त्यहीँ धेरै आत्मविश्वासी व्याख्या वास्तवमा रोकिन्छन्।
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
तालिका जानाजान छोटो छ। यसको मुख्य कुरा यो हो कि प्रत्येक प्रविष्टिले फरक प्रश्नको जवाफ दिन्छ, र कुनै एक फिल्डले तीनवटै भर्दैन।
स्थानीय फर्वार्डरले वास्तविक स्रोत लुकाउँछ
आफ्नो राउटरलाई DNS का रूपमा प्रयोग गर्न सेट गरिएको उपकरण फर्वार्डरतिर संकेत गरिरहेको हुन्छ। त्यो ठेगानाले क्वेरीको अर्को प्राप्तकर्ता पहिचान गर्छ, अन्तमा जवाफ दिने रिजोल्भरलाई होइन। स्थानीय स्टब रिजोल्भरले त्यही अतिरिक्त चरण थप्छ, र प्रत्येक स्थिति आउटपुटमा देखिने भएकाले यसलाई वास्तविक कुरासँग भ्रमित गर्न सजिलो छ।
स्टबले त्यही आउटपुटले पनि सूचीबद्ध गर्ने स्रोतहरूतिर पठाउँछ, सामान्यतया अझ तल। सञ्चालकको बारेमा केही निष्कर्ष निकाल्नु अघि पूरै शृंखला पढ्नुहोस्, किनकि पहिलो पङ्क्ति पूरै जवाफ होइन। अन्यथा तपाईंले रिसेप्सनलाई कम्पनी भनिरहनुभएको छ।
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'दोस्रो आदेशले रिजोल्भरको प्रतिध्वनि नाम प्रयोग गर्छ, जहाँ सञ्चालकले एक प्रकाशित गर्छ, आफूले देख्ने स्रोत ठेगाना रिपोर्ट गर्न। तेस्रोले जवाफ दिने सर्भरको नाम बताउँछ, जो प्रायः तपाईंले कन्फिगर गरेको ठेगाना होइन। सञ्चालक लेख्नु अघि तीनवटै आउटपुट तुलना गर्नुहोस्।
इन्क्रिप्टेड DNS ले के देखिन्छ त्यो परिवर्तन गर्छ, कसले देख्छ त्यो होइन
DNS over HTTPS र DNS over TLS ले क्लाइन्ट र रिजोल्भरबीचको आदानप्रदान सुरक्षित गर्छन्। रिजोल्भरले अझै सोधिएको हरेक नाम पढ्छ, किनकि जवाफ दिनु नै काम हो। परिवर्तन हुने कुरा यो हो कि आदानप्रदान कसले हेर्न सक्छ: स्थानीय नेटवर्कले एक अन्त्यबिन्दुसँगको जडान देख्छ, साधारण पाठको क्वेरीको प्रवाह होइन।
नपरिवर्तन हुने कुरा विश्वासको सम्बन्ध हो, जसले अझै त्यो अन्त्यबिन्दु चलाउने संस्थातिर संकेत गर्छ। आफ्नै सुरक्षित DNS सेटिङ भएको ब्राउजरले अपरेटिङ सिस्टमको रिजोल्भरलाई पूर्ण रूपमा बाइपास गर्न सक्छ। तिनलाई दुई पटक लागू गरिएको एउटा सेटिङ होइन, असहमत हुन सक्ने दुई कन्फिगरेसनका रूपमा लिनुहोस्।
निजी नामहरूलाई फेरि आफ्नै निर्णय चाहिन्छ। कामको टनेलले छानिएका डोमेनहरूलाई संस्थागत रिजोल्भरतिर पठाउन सक्छ, र त्यसलाई सार्वजनिक सेवाले बदल्दा आन्तरिक खोजी भाँचिन सक्छ वा आन्तरिक नामहरू गलत पक्षलाई खुलासा हुन सक्छ। पूरै एडाप्टरको सेटिङ बदल्नु अघि डोमेन नीति जाँच्नुहोस्।
अवलोकन साँघुरो राख्नुहोस्
तुलना गर्दा पुरानो कन्फिगरेसन जोगाएर राख्नुहोस् र एक पटकमा एउटा सेटिङ बदल्नुहोस्। अनुप्रयोग, कार्य, रिजोल्भर नीति, र पुनः जडानपछि सार्वजनिक तथा अनुमति दिइएका निजी नामहरू अझै समाधान हुन्छन् कि भनेर लेख्नुहोस्। दुई परिवर्तन भएको तुलनाले कुनै पनि प्रमाणित गर्दैन। नतिजा अर्को व्यक्तिले भेट्ने ठाउँमा, सेटिङकै छेउमा लेख्नुहोस्।
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comअनुप्रयोग चल्न थाल्यो भने, प्रमाणले अनुमति दिएजति दाबी सानो राख्नुहोस्। त्यो परिवर्तनले एउटा परीक्षणमा मद्दत गर्यो, र यसले अघिल्लो रिजोल्भरले खराब नियतले काम गर्यो कि, टनेल बिग्रिएको थियो कि, वा अर्को उपकरणलाई त्यही प्रतिस्थापन चाहिन्छ कि भन्ने केही भन्दैन। टिकाउ नतिजा त्यस्तो कन्फिगरेसन हो जसको सञ्चालक र उद्देश्य तपाईंले व्याख्या गर्न सक्नुहुन्छ।