TLS वर DNS आणि VPN: कोणता भाग संरक्षित आहे
DoT निवडलेल्या resolver पर्यंतची झेप एन्क्रिप्ट करते, नाव स्वतः नाही. चार तपासण्या: resolver ओळख, ट्रान्झिट मार्ग, अंतर्गत नावे आणि फॉलबॅक.
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 प्रश्न त्यांपैकी एक असेल.