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अनुप्रयोग चालू लागल्यास, पुरावे परवानगी देतात तितका दावा लहान ठेवा। त्या बदलाने एका चाचणीला मदत केली, आणि मागील रिझॉल्व्हरने वाईट हेतूने वागले का, टनेल तुटलेली होती का, किंवा दुसऱ्या उपकरणाला तीच बदली हवी आहे का याबद्दल तो काहीही सांगत नाही। टिकाऊ निकाल म्हणजे असे कॉन्फिगरेशन ज्याचा ऑपरेटर आणि उद्देश तुम्ही समजावून सांगू शकता।