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अगर एप्लिकेशन काम करने लगे, तो दावा उतना ही छोटा रखें जितना साक्ष्य अनुमति देते हैं। उस बदलाव ने एक परीक्षण में मदद की, और यह नहीं बताता कि पिछले रिज़ॉल्वर ने बुरी नीयत से काम किया, टनल टूटी थी, या किसी अन्य डिवाइस को वही प्रतिस्थापन चाहिए। टिकाऊ परिणाम वह कॉन्फ़िगरेशन है जिसका संचालक और उद्देश्य आप समझा सकें।