DNS Over HTTPS स्पष्ट केले: गोपनीयता विरुद्ध सार्वजनिक WiFi फिल्टरिंग

DNS over HTTPS पोर्ट 443 वरील सामान्य HTTPS ट्रॅफिकमध्ये DNS लुकअप पाठवते, जे डिव्हाइस आणि रिझोलव्हर दरम्यान कूटबद्ध केलेले असते, आणि ते 2018 मध्ये IETF मानक बनले.

तुम्ही तुमच्या गेस्ट WiFi वर कंटेंट फिल्टरिंग सक्षम केले आहे, परंतु गेस्टचे ब्राऊझर तरीही तुम्ही ब्लॉक केलेली श्रेणी उघडते. फायरवॉल चालू आहे, नेटवर्क सेटिंग्ज योग्य दिसत आहेत आणि दुसऱ्या डिव्हाइसला अपेक्षित ब्लॉक पेज मिळत आहे. फरक ब्राऊझर कोणत्या रिझॉल्व्हरला विचारतो यात असू शकतो, तुमचा फिल्टर काम करत आहे की नाही यात नाही.

व्हेन्यू ऑपरेटर्स आणि IT प्रमुखांसाठी, DoH ची मुख्य समस्या हीच आहे. ते प्रवास करत असताना लुकअपचे संरक्षण करते, परंतु ब्राउझरने निवडलेले गंतव्यस्थान ते लुकअप तुमच्या नेटवर्कच्या फिल्टरिंग पॉलिसीच्या बाहेर देखील नेऊ शकते.

अनुक्रमणिका

• सोप्या शब्दांत DNS over HTTPS म्हणजे काय
  • केवळ एन्क्रिप्शनचीच नाही, तर ट्रान्सपोर्टची तुलना करा
• DoH लुकअप डिव्हाइसवरून रिझॉल्व्हरपर्यंत कसा प्रवास करतो
  • रिक्वेस्ट आणि रिस्पॉन्सचे अनुसरण करा
  • फिल्टरिंग पॉइंट ओळखा
• DoH चालू असताना तुमचे लुकअप्स कोण पाहू शकते
  • DNS व्हिजिबिलिटीला ब्राउझिंग व्हिजिबिलिटीपासून वेगळे करा
  • विश्वासाचा निर्णय स्पष्ट करा
• सामायिक WiFi वर DoH मूळे DNS फिल्टरिंग का कमकुवत होते
  • बायपास हा मार्गाबद्दल आहे
  • कव्हरेज गृहीत धरण्याऐवजी त्याची चाचणी घ्या
• DoH मुळे वेगावर काय परिणाम होतो आणि फिल्टरिंग अजूनही काय करते
  • केवळ हँडशेक नाही, तर सेशन मोजा
• सामान्य डिव्हाइसेसवर DoH तपासा आणि बदला
  • ब्राउझर आणि ऑपरेटिंग सिस्टमची पाहणी करा
  • प्रभावी मार्गाची पडताळणी करा
• तुमचे DoH नियंत्रणे निवडा आणि त्यांची रचना करा
  • प्रत्येक नियंत्रण त्याच्या वास्तविक व्याप्तीशी जुळवा
  • चाचणीयोग्य कार्यप्रणाली धोरण तयार करा
  • एन्क्रिप्टेड DNS ला स्वीकार्य चाचणीचा भाग बनवा

सरळ शब्दांत DNS over HTTPS चा अर्थ काय आहे

DNS over HTTPS, ज्याला सामान्यतः DoH असे संक्षिप्त केले जाते, ते एन्क्रिप्ट केलेल्या वेब कनेक्शनद्वारे DNS प्रश्न आणि उत्तरे वाहून नेते. DNS रिझॉल्व्हर ही एक अशी सेवा आहे ज्याला डिव्हाइस डोमेन नाव नेटवर्क पत्त्यामध्ये भाषांतरित करण्यासाठी विचारते.

DNS ला फोनबुकसारखे समजा. कनेक्शन उघडण्यापूर्वी, अ‍ॅप्लिकेशनला अ‍ॅड्रेसची आवश्यकता असते, जरी त्याच्या कॅशेमध्ये आधीपासूनच वापरण्यायोग्य उत्तर असू शकते. पारंपारिक DNS सहसा तो प्रश्न वाचनीय स्वरूपात पाठवते.

पोस्टकार्ड हे याचे एक उपयुक्त उदाहरण आहे: ते हाताळणारी कोणतीही व्यक्ती संदेश वाचू शकते. DoH तो प्रश्न एका सीलबंद लिफाफ्यात ठेवते आणि सामान्य सुरक्षित वेब ट्रॅफिकसाठी वापरल्या जाणार्‍या त्याच प्रकारच्या डिलिव्हरी व्हॅनमधून वाहून नेते.

फक्त एन्क्रिप्शन नव्हे, तर ट्रान्सपोर्टची तुलना करा

DoT म्हणजेच DNS over TLS, हे देखील लिफाफा सील करते, परंतु वेगळ्या लेबल असलेल्या डिलिव्हरी प्रवेशद्वाराचा वापर करते. त्यामुळे नेटवर्क ऑपरेटरला त्याच्या डेस्टिनेशन पोर्टवरून त्याचा ट्रॅफिक ओळखणे सोपे जाते.

IETF चे RFC 8484, जे ऑक्टोबर 2018 मध्ये प्रकाशित झाले, ते DoH चे HTTPS एक्सचेंज परिभाषित करते, जे सहसा पोर्ट 53 वरील पारंपारिक DNS च्या उलट पोर्ट 443 वापरते.

पारंपारिक DNS, DNS over TLS आणि DNS over HTTPS यांची तुलना

वैशिष्ट्य	पारंपारिक DNS	DNS over TLS (DoT)	DNS over HTTPS (DoH)
ट्रान्सपोर्ट	UDP किंवा TCP	TLS	HTTPS
सामान्य पोर्ट	53	853	443
स्थानिक नेटवर्कद्वारे वाचनीय	होय	नाही	नाही
पोर्टद्वारे ओळखणे सोपे	होय	होय	नाही, वेब रहदारीसह पोर्ट 443 शेअर करते
पोर्टद्वारे ब्लॉक करणे सोपे	होय	होय	नाही, केवळ पोर्टद्वारे निवडकपणे नाही
व्याख्या केली आहे	मूळ DNS तपशील	DNS over TLS तपशील	RFC 8484

डेडिकेटेड DNS पोर्ट ब्लॉक करणे सोपे आहे. सुरक्षित वेबसाइट्सद्वारे वापरले जाणारे पोर्ट ब्लॉक केल्याने वैध वेब ट्रॅफिक देखील थांबेल, म्हणूनच DoH ला अधिक निवडक नियंत्रणांची आवश्यकता आहे.

एन्क्रिप्शन कशावर फिल्टर केले जाईल हे ठरवत नाही. एक रिझॉल्व्हर येणाऱ्या DoH विनंतीला डिक्रिप्ट करू शकतो, कंटेंट किंवा थ्रेट पॉलिसी लागू करू शकतो आणि त्याचे उत्तर सुरक्षितपणे परत करू शकतो. महत्त्वाचे प्रश्न हे आहेत की तो रिझॉल्व्हर कोण चालवतो आणि तो कोणाच्या पॉलिसीचे अनुसरण करतो.

नियंत्रणांचे पुनरावलोकन करताना ही तुलना हातात ठेवा. पारंपारिक DNS किंवा DoT हाताळणारा नियम आपोआप DoH हाताळत नाही.

DoH लुकअप डिव्हाइसवरून रिझॉल्व्हरकडे कसा जातो

पार्सल पोहोचवण्यापूर्वी कुरिअरला पत्त्याची आवश्यकता असते. त्याचप्रमाणे, एखाद्या ब्राउझरकडे उत्तर आधीच कॅश केलेले नसल्यास, हॉटेल बुकिंग पृष्ठाशी कनेक्ट होण्यापूर्वी त्याला गंतव्य पत्त्याची आवश्यकता असते.

हा आकृतीबंध ब्राउझरपासून रिझॉल्व्हरपर्यंत आणि पुन्हा मागे येणाऱ्या लुकअपचा मागोवा घेतो.

रिक्वेस्ट आणि रिस्पॉन्स फॉलो करा

1. ब्राउझरला पत्त्याची गरज असते. हे तपासते की बुकिंग साइटसाठी त्याच्याकडे आधीच वापरण्यायोग्य उत्तर आहे का. कॅशे हिटमुळे नवीन शोधाची गरज पूर्णपणे टळू शकते, त्यामुळे स्थानिक नेटवर्कला त्या क्रियेसाठी DNS एक्सचेंज दिसणार नाही.

2. हे DNS प्रश्न तयार करते. त्याला नवीन उत्तराची आवश्यकता असल्यास, ब्राउझर डोमेन नाव असलेला प्रश्न तयार करतो. या टप्प्यावर, प्रश्न अजूनही डिव्हाइसच्या आत असतो, WiFi वरून प्रवास करत नाही.

3. हे DoH रिव्हॉल्व्हर निवडते. ब्राउझर त्याच्या कॉन्फिगर केलेल्या रिव्हॉल्व्हरसाठी HTTPS विनंती तयार करतो. स्थानिक नेटवर्क गंतव्य पत्ता आणि कनेक्शन मेटाडेटा पाहू शकते, परंतु ते एनक्रिप्टेड DNS संदेशामधील डोमेन थेट वाचू शकत नाही.

4. हे सुरक्षित कनेक्शन स्थापित करते किंवा पुन्हा वापरते. आवश्यक असल्यास, सुरक्षित विनंती पाठवण्यापूर्वी डिव्हाइस TLS हँडशेक पूर्ण करते. सततच्या HTTP कनेक्शनसह, त्यानंतरचे प्रश्न ते कनेक्शन पुन्हा वापरू शकतात; नेटवर्कला एनक्रिप्टेड ट्रॅफिक दिसतो, ज्यामध्ये त्याची वेळ आणि आकार समाविष्ट असतो.

5. रिव्हॉल्व्हर उत्तर परत करतो. रिव्हॉल्व्हर प्रश्नावर प्रक्रिया करतो आणि DNS उत्तर एनक्रिप्टेड HTTP प्रतिसादामध्ये ठेवतो. नेटवर्क रिव्हॉल्व्हरकडून परत येणारा ट्रॅफिक पाहू शकते, उत्तरातील वाचण्यायोग्य सामग्री नाही.

6. ब्राउझर वेबसाइटशी कनेक्ट होतो. वेबसाइट कनेक्शन सुरू करण्यासाठी ते परत आलेला पत्ता वापरते. स्थानिक नेटवर्क ते नवीन गंतव्यस्थान पाहू शकते, जे पूर्वीचा DNS प्रश्न वाचण्यापासून वेगळे आहे.

कॅशिंग आणि रिझोल्यूशनवरील अधिक तपशीलांसाठी, DNS लुकअप काय करते याचे स्पष्टीकरण पत्ता-शोधण्याच्या प्रक्रियेला स्वतः वेबसाइट कनेक्शनपासून वेगळे करते.

फिल्टरिंग पॉइंट ओळखा

DNS रिझोल्यूशन आवश्यक असलेल्या नवीन कनेक्शनसाठी, पृष्ठ सामग्री लोड होण्यापूर्वी लुकअप होतो. यामुळे मान्यताप्राप्त रिझोलव्हरला ब्राउझर कनेक्ट होण्यापूर्वी ब्लॉक केलेल्या गंतव्यस्थानास नाकारण्याची संधी मिळते.

स्वतंत्रपणे कॉन्फिगर केलेला ब्राउझर तो निर्णय इतर कुठेतरी पाठवू शकतो. त्यानंतर ठिकाणाच्या रिझॉल्व्हरला मूल्यांकन करण्यासाठी कोणताही प्रश्न प्राप्त होत नाही.

सोबतीचा व्हिडिओ या प्रक्रियेचा मागोवा घेण्याचा आणखी एक मार्ग ऑफर करतो.

DoH सुरू असताना तुमचे लुकअप कोण पाहू शकते

DoH प्रत्येकापासून ब्राऊझिंग लपवत नाही. हे डिव्हाइस आणि त्याने निवडलेला रिझॉल्व्हर यांमधील सामान्य निरीक्षकांपासून DNS एक्सचेंजचे रक्षण करते, परंतु तो प्रश्न सोडवण्यासाठी रिझॉल्व्हरने तो वाचणे आवश्यक आहे.

हा फरक सामायिक केलेल्या WiFi वर महत्त्वाचा आहे. एखाद्या गेस्टला स्थानिक इंटरसेप्शनपासून वाजवीपणे संरक्षण हवे असू शकते, तर हॉस्पिटल किंवा शाळेला त्यांची सुरक्षितता आणि थ्रेट कंट्रोल्स अजूनही लागू होत असल्याचे निश्चित असणे आवश्यक आहे.

DoH तुम्ही DNS अॅक्टिव्हिटीसाठी कोणावर विश्वास ठेवता ते बदलते; ते कोणावर तरी विश्वास ठेवण्याची गरज पूर्णपणे काढून टाकत नाही.

DNS दृश्यता आणि ब्राउझिंग दृश्यता वेगळी करा

हे टेबल अतिरिक्त प्रायव्हसी रिले, VPN किंवा इंटरसेप्शन सिस्टीमशिवाय सामान्य DoH वापराचे वर्णन करते. DNS मेसेज वाचणे आणि इतर नेटवर्क अ‍ॅक्टिव्हिटीवरून डेस्टिनेशनचा अंदाज लावणे या वेगवेगळ्या क्षमता आहेत.

DoH वापरात असताना DNS लुकअप कोण पाहू शकते

निरीक्षक	डोमेन नाव पाहतो	DoH वापरात असल्याचे पाहतो	हे महत्त्वाचे का आहे
त्याच WiFi वरील इतर डिव्हाइसेस	नाही, एनक्रिप्टेड लुकअपमधून नाही	सामान्य पीअर ॲक्सेसद्वारे क्वचितच	DNS संदेशाचे पॅसिव्ह रीडिंग ब्लॉक केले जाते
व्हेन्यू किंवा ISP नेटवर्क	नाही, DoH एक्सचेंजच्या आत नाही	बऱ्याचदा, ज्ञात रिव्हॉल्व्हर ॲड्रेसवरील ट्रॅफिकद्वारे	स्थानिक DNS नियंत्रणे इतरत्र पाठवलेल्या क्वेरींचे मूल्यमापन करू शकत नाहीत
तुम्ही भेट देता त्या वेबसाइट्स	फक्त तुम्ही कनेक्ट केलेली साइट	केवळ वेबसाइट कनेक्शनवरून नाही	वेबसाइटला तुमच्या असंबधित DNS क्वेरी प्राप्त होत नाहीत
DoH रिव्हॉल्व्हर ऑपरेटर	होय, त्याला मिळालेली प्रत्येक क्वेरी	होय	एक थेट कनेक्शन तुमच्या स्त्रोत ॲड्रेससह त्या क्वेरी उघड करतो
ब्राउझर किंवा OS व्हेंडर	फक्त जर तो रिव्हॉल्व्हर चालवत असेल किंवा संबंधित टेलिमेट्री प्राप्त करत असेल	सॉफ्टवेअरला त्याचा कॉन्फिगर केलेला मोड माहित असतो; व्हेंडर रिपोर्टिंगसाठी टेलिमेट्री आवश्यक असते	सॉफ्टवेअर कॉन्फिगरेशन म्हणजे स्वयंचलित व्हेंडर दृश्यमानता नाही

रिझॉल्व्हरला डिव्हाइसद्वारे केलेले प्रत्येक लुकअप दिसेलच असे नाही. दुसरे अ‍ॅप्लिकेशन वेगळा रिझॉल्व्हर वापरू शकते आणि कॅश केलेल्या उत्तरांसाठी कोणत्याही क्वेरीची आवश्यकता नसू शकते. ते फक्त त्याला पाठवलेल्या रिक्वेस्ट्स पाहते.

त्याचप्रमाणे, ब्राऊझर व्हेंडर फक्त ब्राऊझर पुरवतो म्हणून त्याला आपोआप DNS हिस्ट्री मिळत नाही. रिझॉल्व्हर ऑपरेशन, सॉफ्टवेअर सेटिंग्ज आणि टेलिमेट्री कलेक्शन या वेगवेगळ्या भूमिका आहेत.

विश्वासार्हतेचा निर्णय स्पष्ट करा

मॅनेज केलेल्या Firefox इन्स्टॉलेशन्ससाठी, Mozilla चे DNS ओव्हर HTTPS पॉलिसी दस्तऐवजीकरण रिझॉल्व्हर कॉन्फिगरेशनसाठी आणि वापरकर्ते ते बदलू शकतात की नाही यासाठी नियंत्रणे प्रदान करते. ब्राऊझरचे वर्तन संस्थेच्या DNS गव्हर्नन्सशी संरेखित करण्याचा हा एक व्यावहारिक मार्ग आहे.

एखादे ठिकाण (venue) किंवा ISP अजूनही डेस्टिनेशन अ‍ॅड्रेसेस, कनेक्शनची वेळ आणि ट्रॅफिकचे प्रमाण पाहू शकते. इतर प्रोटोकॉल मेटाडेटा देखील साईट ओळखण्यात मदत करू शकतो, त्यामुळे एन्क्रिप्टेड DNS प्रश्न ही अनामित (anonymous) ब्राऊझिंगची शाश्वती नाही.

रिझॉल्व्हर मंजूर करण्यापूर्वी एक संक्षिप्त विश्वास मूल्यांकन (trust assessment) वापरा:

• ऑपरेटरचे नाव निश्चित करा. ब्राउझरच्या डीफॉल्ट लेबलवर अवलंबून राहण्याऐवजी कोणती संस्था प्रश्न प्राप्त करते ते स्थापित करा.
• रिटेंशन अटी वाचा. कोणती क्वेरी आणि कनेक्शन माहिती संग्रहित केली जाते, किती काळासाठी आणि कोणत्या उद्देशासाठी संग्रहित केली जाते ते तपासा.
• हक्कक्षेत्र आणि प्रवेश तपासा. ऑपरेटर माहिती कुठे प्रोसेस करतो आणि ती कोणाला मिळू शकते ते समजून घ्या.
• दृश्यता आणि जबाबदारी यांची सांगड घाला. तुमच्या IT टीमला कोणत्या सुरक्षा घटनांची चौकशी करणे आवश्यक आहे आणि कोणत्या ब्राउझिंग तपशीलांची नोंद ठेवू नये ते ठरवा.

गोपनीयता किंवा व्यवस्थापनक्षमता यापैकी कशाला जास्त महत्त्व आहे हा महत्त्वाचा प्रश्न नाही. महत्त्वाचा प्रश्न हा आहे की तुम्ही निवडलेला DNS पाथ वापरकर्त्यांना योग्य गोपनीयता प्रदान करतो का, आणि त्याच वेळी संस्थेला तिची घोषित जबाबदारी पार पाडण्यास सक्षम ठेवतो का.

सामायिक WiFi वर DoH मुळे DNS फिल्टरिंग का कमकुवत होते

एक हॉटेल अतिथींना स्थानिक सेवा शोधण्यात मदतीसाठी रिसेप्शन नंबर देते. बहुतांश अतिथी डेस्कला कॉल करतात, परंतु दुसरा अतिथी त्याऐवजी डिरेक्टरी ॲप वापरतो. रिसेप्शन स्वतःच्या शिफारशी नियंत्रित करू शकते, परंतु त्या ॲपद्वारे दिलेल्या उत्तरांवर त्याचे नियंत्रण नसते.

नेटवर्क DNS समान रीतीने कार्य करते. तुमचे नेटवर्क एक रिझॉल्व्हर प्रदान करते, परंतु स्वतःचे DoH कॉन्फिगरेशन असलेला ब्राउझर त्याऐवजी बाह्य सेवेला विचारू शकतो.

हे चित्र नेटवर्कच्या DNS डेस्कभोवतीचा तो पर्याय मार्ग दाखवते.

बायपास हा मार्गाबद्दल आहे

समस्या अशी नाही की कूटबद्ध केलेली क्विरी कधीही फिल्टर केली जाऊ शकत नाही. समस्या ही आहे की तुमचे फिल्टर ज्या क्विरीला कधी प्राप्तच करत नाही त्यावर पॉलिसी लागू करू शकत नाही.

कुटुंबाच्या आकर्षणाच्या ठिकाणी असलेल्या अतिथी नेटवर्कवर, याचा अर्थ असा असू शकतो की विशिष्ट ब्राउझरवर अश्लील-सामग्री ब्लॉक लागू होत नाही. कर्मचाऱ्यांच्या नेटवर्कवर, एक हानीकारक ॲप्लिकेशन अमान्य केलेल्या रिझॉल्व्हरद्वारे कमांड-ॲंड-कंट्रोल डोमेन रिझॉल्व्ह करू शकते.

त्याचे परिणाम कोणते नियंत्रणे DNS वर अवलंबून आहेत यावर अवलंबून असतात:

• नेटवर्क विशिष्ट पॉलिसी. SSID किंवा VLAN ला दिलेले नियम मंजूर रिव्हॉल्व्हर पाथबाहेर पाठवलेल्या प्रश्नांवर नियंत्रण ठेवणार नाहीत.
• शोध निर्बंध. खाता स्तर किंवा एंडपॉईंट निर्बंध लागू असले तरीही, DNS आधारित सुरक्षित शोध अंमलबजावणी बायपास केली जाऊ शकते.
• थ्रेट ब्लॉकिंग. DNS फिल्टर अदृश्य लुकअप नाकारू शकत नाही, जरी त्याच्या थ्रेट सूचीमध्ये विनंती केलेला डोमेन असला तरीही.

एन्क्रिप्टेड-DNS उपयोजनाचा एक मापन अभ्यास Firefox टेलिमेट्रीचा अहवाल देतो ज्यामध्ये 2025 दरम्यान 9.54 ट्रिलियन डेस्कटॉप हँडशेक्सपैकी अंदाजे 13.91% DoH वापरले गेले. यात असा मापन डेटासेट देखील वर्णन केला आहे ज्यामध्ये DoH हे DoT पेक्षा अंदाजे 6.4 पट अधिक प्रचलित होते.

ही निरीक्षणे तुमच्या ठिकाणाचे (venue) फिल्टर बायपास करणाऱ्या डिव्हाइसेसचा वाटा निश्चित करत नाहीत. ब्राऊझरचे डीफॉल्ट्स, प्रादेशिक रोलआउट, रिझॉल्व्हर सुसंगतता आणि अ‍ॅडमिनिस्ट्रेटरच्या पॉलिसी हे सर्व DoH सक्रिय आहे की नाही यावर परिणाम करतात.

गृहीत धरण्याऐवजी चाचणी कव्हरेज तपासा

कर्मचार्‍यांच्या लॅपटॉपवर यशस्वी ब्लॉक केल्याने अतिथींच्या वैयक्तिक फोनवर तितकेच कव्हरेज सिद्ध होत नाही. डिव्हाइसेस भिन्न ब्राउझर, DNS सेटिंग्ज किंवा टनेल वापरू शकतात.

तुमच्या WiFi सामग्री फिल्टरकडे परिभाषित ट्रॅफिक पाथ असलेले नियंत्रण म्हणून पहा. तुमचे अभ्यागत सोबत आणत असलेली डिव्हाइसेस आणि ॲप्लिकेशन्स वापरून त्या पाथची चाचणी करा.

केवळ नेटवर्क-प्रदान केलेल्या रिझोलव्हरवर आधारित फिल्टरिंग हे बाय डीफॉल्ट पूर्ण कव्हरेज राहिलेले नाही. यासाठी सहाय्यक नियंत्रणे आणि पॉलिसीच्या बाहेर काय राहते याचा प्रामाणिक हिशोब आवश्यक आहे.

DoH मुळे वेगात काय परिणाम होतो आणि फिल्टरिंग अजूनही काय करते

एंक्रिप्शनमुळे अतिरिक्त काम वाढते, परंतु व्यावहारिक प्रश्न असा आहे की युजर्सना स्लो सेशन जाणवते का. प्रारंभिक कनेक्शन सेटअप आणि वारंवार होणाऱ्या लुकअप्सचा खर्च वेगवेगळा असतो, त्यामुळे एकाच नवीन रिक्वेस्टची चाचणी केल्याने दिशाभूल करणारे चित्र दिसू शकते.

DNS ट्रान्सपोर्ट्सची एक प्रायोगिक तुलना तिच्या नो-डिले लोकल बेसलाइनमध्ये 1 मिलिसेकंदपेक्षा कमी UDP आणि TLS प्रतिसादांची नोंद करते, तर HTTP/2 सातत्याने 10 मिलिसेकंदपेक्षा कमी राहिले; खालील निकाल वेन्यू परफॉर्मन्सचा अंदाज लावण्याऐवजी अभ्यासाच्या प्रायोगिक संदर्भास कायम ठेवतात.

उल्लेख केलेल्या अभ्यासातील प्रोटोकॉलनुसार DNS लुकअप लेटन्सी

प्रोटोकॉल	रिपोर्ट केलेला निकाल	संदर्भ
UDP	1 ms पेक्षा कमी	नो-डिले लोकल बेसलाइन
TLS	1 ms पेक्षा कमी	नो-डिले लोकल बेसलाइन
HTTP/2	सातत्याने 10 ms पेक्षा कमी	कनेक्शनचा पुनर्वापर आणि मल्टिप्लेक्सिंगमुळे ओव्हरहेड कमी होण्यास मदत होते
HTTP/1.1	मोठ्या प्रमाणावर बदलत राहते	पाइपलाइनिंग मर्यादांमुळे असे होते
पब्लिक DoH विरुद्ध पारंपारिक DNS	प्रति नाव मंद	एकूण पेज लोड वेळेत कोणतीही मोठी वाढ दिसून आली नाही

फक्त हँडशेकला नव्हे, तर संपूर्ण सत्राला मोजा

सततचे कनेक्शन (Persistent connections) क्लायंटला सेटअप खर्च पुढील क्विरीजवर पसरवण्याची अनुमती देतात. मल्टीप्लेक्सिंगमुळे प्रत्येक प्रश्नासाठी स्वतंत्र सुरक्षित कनेक्शन स्थापित न करता एकाधिक एक्सचेंज हाताळणे शक्य होते.

नवीन कनेक्शन सुरू होण्यापूर्वी DNS फिल्टरिंग तरीही डोमेन नाकारू शकते, जर विनंती फिल्टरिंग रिझॉल्व्हरपर्यंत पोहोचली असेल. जाहिरात आणि ट्रॅकर ब्लॉकिंगमुळे त्यानंतरच्या विनंत्या कमी होऊ शकतात, परंतु केवळ एन्क्रिप्शनने जाहिराती हटवल्या जात नाहीत किंवा पृष्ठ जलद लोड होत नाही.

वास्तविक समस्या उघड करणाऱ्या ऑपरेशनल सिग्नेल्सचा मागोवा घ्या:

• हँडशेख त्रुटी. कनेक्शन सेटअप त्रुटी आणि रीट्राय शोधा.
• कॅशे-हिट दर. कॅश केलेल्या प्रतिसादांना नवीन रिझोल्यूशनपासून वेगळे करा.
• रिझॉल्व्हर प्रतिसाद वेळ. व्यस्त अतिथी सत्रांदरम्यान वर्तनाचे मोजमाप करा.
• फॉलबॅक वर्तन. त्रुटींमुळे डिव्हाइसेस रिझॉल्व्ह करणे थांबवतात की पूर्वसूचनेशिवाय दुसऱ्या मार्गावर स्विच होतात ते तपासा.

व्यावहारिक नियम: ब्राउझिंग, पॉलिसी अंमलबजावणी आणि अपयश पुनर्प्राप्ती (failure recovery) ची स्वतंत्र मंजुरी चाचण्या म्हणून नव्हे, तर एकत्रित चाचणी करा.

केवळ लॅटन्सीच्या गृहितकांवरून प्रोटोकॉल निवडण्यापेक्षा जवळपासचा, लवचिक रिझोलव्हर एंडपॉइंट हा अधिक चांगला प्रारंभ बिंदू आहे. वास्तववादी लोड अंतर्गत आपल्या नेटवर्कवर परिणामाची पुष्टी करा.

सामान्य उपकरणांवर DoH तपासा आणि बदला

एकाच WiFi वरील डिव्हाइसेस वेगळे वर्तन का करतात याचे स्पष्टीकरण ब्राउझर सेटिंग देऊ शकते. रीलिझ दरम्यान मेनू लेबल्स बदलतात, त्यामुळे खालील मार्ग दृश्यमान नसल्यास Settings शोध वापरा.

ब्राउझर आणि ऑपरेटिंग सिस्टमची तपासणी करा

1. Chrome: Settings, Privacy and security, Security, नंतर Use secure DNS उघडा. ते सध्याच्या प्रदात्याचे अनुसरण करते की दुसऱ्या सेवेचा उल्लेख करते ते तपासा.
2. Firefox: Settings, Privacy & Security, नंतर DNS over HTTPS उघडा. Off, Default Protection किंवा Max Protection सह संरक्षण मोड आणि निवडलेल्या रिझॉल्व्हरचे पुनरावलोकन करा.
3. Edge: Settings, Privacy, search and services, Security, नंतर Use secure DNS उघडा. मॅनेज्ड पॉलिसी सेटिंग लॉक करू शकते.
4. Android: Settings, Network & internet, नंतर Private DNS उघडा. हे सेटिंग DoH ऐवजी DoT वापरते; ब्राउझर-स्तरीय सुरक्षित DNS साठी स्वतंत्र तपासणी आवश्यक आहे.
5. iOS आणि macOS: इंस्टॉल केलेले कॉन्फिगरेशन प्रोफाइल, डिव्हाइस-व्यवस्थापन सेटिंग्ज आणि DNS-संबंधित ॲप्सची पाहणी करा. एनक्रिप्ट केलेले DNS प्रोफाइल ब्राउझरपासून स्वतंत्रपणे कार्य करू शकते.

प्रभावी मार्गाची पडताळणी करा

ब्राउझर सेटिंग काहीही असली तरी सिस्टीम VPN DNS ला स्वतःच्या टनेलद्वारे घेऊन जाऊ शकते. तसेच एखादे अॅप स्वतंत्र एन्क्रिप्टेड DNS सेवा पुरवते का ते देखील तपासा.

वास्तविक ब्राउझर किंवा ॲपवरून कोणती रिझॉल्व्हर नवीन चाचणी लुकअप प्राप्त करते याची पुष्टी करा. केवळ सेटिंग्ज स्क्रीनवर विश्वास ठेवण्याऐवजी मंजूर केलेल्या रिझॉल्व्हर लॉग्जसोबत ब्राउझर डायग्नोस्टिक्स किंवा रिझॉल्व्हर-आयडेंटिफिकेशन चाचणी वापरा.

तुमचे DoH नियंत्रणे निवडा आणि त्यांचे स्तर तयार करा

डिव्हाइस मालकी आणि पॉलिसी गरजेनुसार नियंत्रणे स्तरीकृत करा. मॅनेज केलेले कर्मचाऱ्यांचे लॅपटॉप लागू केलेल्या कॉन्फिगरेशनचे अनुसरण करू शकतात; वैयक्तिक गेस्ट फोन साधारणपणे करू शकत नाहीत. दोन्ही गटांवर समान नियंत्रणे लागू केल्याने टाळता येण्याजोग्या त्रुटी किंवा अनावश्यक अडथळे निर्माण होतात.

तुम्ही बाह्य DoH ला अनुमती देऊ शकता आणि कमी झालेली स्थानिक DNS दृश्यमानता स्वीकारू शकता, ते प्रतिबंधित करू शकता आणि सुसंगतता धोके स्वीकारू शकता किंवा निवडीनुसार गेस्ट-नेटवर्क नियंत्रणांसह मॅनेज्ड-डिव्हाइस पॉलिसी एकत्र करू शकता. ही स्तरीकृत पद्धत तुम्हाला कशाचे संरक्षण केले आहे आणि कशाचे नाही याचे अधिक स्पष्ट विधान देते.

प्रत्येक नियंत्रणाला त्याच्या वास्तविक व्याप्तीशी जुळवा

नेटवर्क नियंत्रणे उपयुक्त आहेत, परंतु ती प्रत्येक एन्क्रिप्टेड रिझॉल्व्हर ओळखण्यायोग्य बनवत नाहीत. खाजगी रिझॉल्व्हर, बदलणारा अ‍ॅड्रेस किंवा VPN टनेल परिचित सेवांच्या सूचीभोवती बनवलेले गृहीतके खोडून काढू शकतात.

सामायिक आणि व्यवस्थापित नेटवर्क्सवर DoH साठी नियंत्रणे

नियंत्रण	हे काय थांबवते	हे कोठे लागू होते	तडजोड (Trade-off)
आउटबाउंड पोर्ट 853 ब्लॉक करा	स्टँडर्ड-पोर्ट DNS over TLS	फायरवॉल किंवा गेटवे	सामान्य HTTPS वरील DoH वर काहीही परिणाम करत नाही
पोर्ट 53 ला नेटवर्क रिव्हॉल्व्हरवर फोर्स करा	प्लेन DNS बायपास	गेटवे अंमलबजावणी, DHCP कॉन्फिगरेशनद्वारे समर्थित	DoH कडे पूर्णपणे दुर्लक्ष करते; केवळ DHCP अनुपालन सक्तीचे करत नाही
माहित असलेले सार्वजनिक DoH रिव्हॉल्व्हर पत्ते ब्लॉक करा	सूचीबद्ध रिव्हॉल्व्हरशी जोडणी	फायरवॉल किंवा सक्षम गेटवे	याद्या जुन्या होतात, नवीन रिव्हॉल्व्हर येतात, काही ॲप्स बंद पडतात
मॅनेज्ड पॉलिसीद्वारे ब्राउझर DoH अक्षम करा	कव्हर केलेल्या ब्राउझरमध्ये ब्राउझर-स्तरीय बायपास	मॅनेज्ड लॅपटॉप आणि कर्मचाऱ्यांची उपकरणे	गेस्ट WiFi वरील वैयक्तिक फोनपर्यंत पोहोचू शकत नाही
MDM द्वारे नेटवर्क रिव्हॉल्व्हर लागू करा	डिव्हाइस पॉलिसीद्वारे कव्हर केलेले अनधिकृत DNS बदल	एनरोल केलेले कर्मचारी आणि कॉर्पोरेट उपकरणे	एनरोलमेंट आणि प्लॅटफॉर्म सपोर्ट आवश्यक आहे; गेस्ट याच्या बाहेर राहतात
DoH स्वीकारा आणि एंडपॉइंटवर फिल्टर करा	नेटवर्कच्या बाजूने काहीही नाही	फक्त मॅनेज्ड एंडपॉइंट्स	गेस्ट डिव्हाइसेस एंडपॉइंट पॉलिसीच्या बाहेर राहतात

रिझोलव्हरचा पत्ता ब्लॉक केल्याने त्या पत्त्यावर होस्ट केलेल्या असंबद्ध सेवा देखील ब्लॉक होऊ शकतात. फायरवॉलच्या कूटबद्ध-DNS श्रेणीला कायमस्वरूपी, सर्वसमावेशक यादी मानणे टाळा.

जिथे तुम्हाला डोमेन रिझोल्यूशनच्या पलीकडे नियंत्रण आवश्यक असेल, तिथे एंडपॉइंट आणि नेटवर्क पॉलिसींसह secure web gateway चे मूल्यमापन करा. विशेषत: जेव्हा डिव्हाइसेस संस्थेच्या मालकीची नसतात, तेव्हा उपयोजन आवश्यकता काळजीपूर्वक तपासा.

एक चाचणी करण्यायोग्य ऑपरेटिंग पॉलिसी तयार करा

तुम्हाला ज्या सेवेची पूर्तता करायची आहे तिथून सुरुवात करा. स्टाफ अ‍ॅडमिनिस्ट्रेशन नेटवर्क, सार्वजनिक ग्रंथालय कनेक्शन आणि मुलांच्या उपक्रमांचे ठिकाण यासाठी रास्तपणे वेगवेगळे निर्बंध आणि युजर्सना वेगवेगळ्या स्पष्टीकरणांची आवश्यकता असू शकते.

या उपयोजन चेकलिस्टचा वापरा करा:

1. आवश्यक पॉलिसींची यादी तयार करा. कंटेंन्ट नियंत्रणे किंवा थ्रेट फिल्टरिंग आवश्यक असलेले SSIDs, VLANs आणि डिव्हाइस ग्रुप्स ओळखा आणि प्रत्येकासाठी एक मालक नियुक्त करा.
2. मॅनेज केलेली डिव्हाइसेस गेस्ट BYOD पासून वेगळी करा. ब्राउझर पॉलिसी किंवा MDM कुठे लागू केले जाऊ शकते आणि कुठे फक्त नेटवर्क नियंत्रणे उपलब्ध आहेत याची नोंद ठेवा.
3. सामान्य DNS बायपास मार्ग बंद करा. तुमच्या पॉलिसीनुसार आवश्यक असेल तेथे, आउटबाउंड DoT ब्लॉक करा आणि पारंपारिक DNS ला मंजूर केलेल्या रिव्हॉल्व्हरपुरते मर्यादित करा. दोन्ही सपोर्टेड नेटवर्क ॲड्रेस फॅमिली समाविष्ट करा.
4. मॅनेज केलेली ब्राउझर पॉलिसी लागू करा. मंजूर केलेला DNS पाथ कॉन्फिगर करा आणि कर्मचाऱ्यांच्या उपकरणांवर असमर्थित युझर ओव्हरराइड्स रोखा.
5. गेस्ट नेटवर्क रिव्हॉल्व्हर निर्बंध राखा. ब्लॉक केलेल्या रिव्हॉल्व्हर ॲड्रेसचे नियमित पुनरावलोकन करा, अपवाद तपासा आणि अयोग्य कोलेटरल ब्लॉकिंगला कारणीभूत ठरलेले नियम काढून टाका.
6. सोप्या भाषेतील गेस्ट सूचना प्रकाशित करा. कोणत्या श्रेणी फिल्टर केल्या आहेत, कोणती नेटवर्क माहिती नोंदवली गेली आहे आणि एनक्रिप्टेड DNS किंवा VPN वापरावरील कोणत्याही निर्बंधांचे स्पष्टीकरण द्या.
7. प्रत्येक नेटवर्कवर वास्तविक डिव्हाइसची चाचणी घ्या. अनुमती दिलेल्या साइट्स, ब्लॉक केलेल्या श्रेणी, मंजूर केलेली सुरक्षा चाचणी गंतव्यस्थाने, रिव्हॉल्व्हर अपयश आणि VPN वर्तनाची तपासणी करा.

लाँच करण्यापूर्वी: ब्लॉक पृष्ठ हे सिद्ध करते की विशिष्ट विनंती फिल्टर केली गेली होती, हे नाही की डिव्हाइसवरील प्रत्येक ॲप्लिकेशन समान मार्गाचे अनुसरण करते.

एन्क्रिप्टेड DNS ला स्वीकार्य चाचणीचा भाग बनवा

Shield वापरण्यासाठी, तुम्ही नेटवर्कचे DNS Shield कडे निर्देशित करता. आम्ही संरक्षित करत असलेल्या नेटवर्कवरील, प्रत्येक डिव्हाइसवरील प्रत्येक DNS लुकअपचे उत्तर देतो, डिव्हाइसवर बंद करण्यासाठी काहीही नसते; त्यामुळे बाह्य रिझॉल्व्हर आणि बोगद्याचे मार्ग नेटवर्कच्या संरक्षण डिझाइनमध्ये समाविष्ट केले पाहिजेत.

तुम्ही Purple Shield चे ट्रायल घेण्यापूर्वी, आमचे तज्ज्ञ तुमचे नेटवर्क VPNs आणि एन्क्रिप्ट केलेले DNS कसे हाताळते ते दाखवतात. कोणत्या विनंत्या सुरक्षित DNS पाथपर्यंत पोहोचतात, कोणते नियंत्रणे ते लागू करतात आणि जेव्हा एखादे डिव्हाइस दुसरा मार्ग निवडण्याचा प्रयत्न करते तेव्हा काय होते हे स्थापित करण्यासाठी त्या चर्चेचा वापर करा.

गेस्ट अ‍ॅक्सेस बदलण्यापूर्वी स्वीकृतीचे निकष (acceptance criteria) सेट करा. सक्षम केलेले फिल्टर सर्व काही पाहत आहे असा गृहीत धरण्यापेक्षा मंजुरी मिळालेला रिझॉल्व्हर, दस्तऐवजीकरण केलेली अपवाद प्रक्रिया आणि पुनरावृत्ती करता येण्याजोग्या डिव्हाइस चाचण्या अधिक मजबूत पाया प्रदान करतात.

---

Purple Shield गेस्ट डिव्हाइसेसवर एजंट इन्स्टॉल न करता संरक्षणात्मक DNS, कंटेंट फिल्टरिंग, थ्रेट डिफेन्स आणि ॲड ब्लॉकिंग प्रदान करते. तुमच्या SSIDs, फिल्टरिंग पॉलिसी आणि तुमचे नेटवर्क एन्क्रिप्टेड DNS आणि VPNs कसे हाताळते याबद्दल ट्रायलपूर्व चर्चेची व्यवस्था करण्यासाठी Purple Shield ला भेट द्या.