DNS Over HTTPS की व्याख्या: गोपनीयता बनाम सार्वजनिक WiFi फ़िल्टरिंग

DNS over HTTPS पोर्ट 443 पर सामान्य HTTPS ट्रैफ़िक के अंदर DNS लुकअप भेजता है, जो डिवाइस और रिज़ॉल्वर के बीच एन्क्रिप्टेड होता है, और यह 2018 में एक IETF मानक बन गया।

आपने अपने गेस्ट WiFi पर कंटेंट फ़िल्टरिंग सक्षम की है, लेकिन किसी गेस्ट का ब्राउज़र अभी भी उस श्रेणी को खोलता है जिसे आपने सोचा था कि आपने ब्लॉक कर दिया है। फ़ायरवॉल चल रहा है, नेटवर्क सेटिंग्स सही दिखती हैं, और किसी अन्य डिवाइस को अपेक्षित ब्लॉक पेज मिलता है। अंतर इस बात में हो सकता है कि ब्राउज़र किस रिज़ॉल्वर से पूछता है, न कि इसमें कि आपका फ़िल्टर काम कर रहा है या नहीं।

स्थान ऑपरेटरों और IT लीड्स के लिए, DoH के साथ यही केंद्रीय मुद्दा है। यह यात्रा के दौरान लुकअप की सुरक्षा करता है, लेकिन ब्राउज़र का गंतव्य का चयन उस लुकअप को आपके नेटवर्क की फ़िल्टरिंग नीति से बाहर भी ले जा सकता है।

विषय-सूची

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

साधारण शब्दों में HTTPS के माध्यम से DNS (DoH) का क्या अर्थ है

DNS over HTTPS, जिसे आमतौर पर संक्षेप में DoH कहा जाता है, एक एन्क्रिप्टेड वेब कनेक्शन के माध्यम से DNS प्रश्नों और उत्तरों को ले जाता है। DNS रिज़ॉल्वर वह सेवा है जिसे कोई डिवाइस किसी डोमेन नाम को नेटवर्क पते में अनुवाद करने के लिए कहता है।

DNS को एक फोनबुक की तरह समझें। कनेक्शन खोलने से पहले, एक एप्लिकेशन को एक पते की आवश्यकता होती है, भले ही उसके कैश में पहले से ही एक उपयोगी उत्तर मौजूद हो। पारंपरिक DNS आमतौर पर उस प्रश्न को पढ़ने योग्य रूप में भेजता है।

एक पोस्टकार्ड एक उपयोगी उपमा है: इसे संभालने वाला कोई भी व्यक्ति संदेश पढ़ सकता है। DoH प्रश्न को एक सीलबंद लिफाफे में रखता है और उसे उसी प्रकार की डिलीवरी वैन के अंदर ले जाता है जिसका उपयोग सामान्य सुरक्षित वेब ट्रैफ़िक के लिए किया जाता है।

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

DNS over TLS, या DoT, भी लिफाफे को सील करता है, लेकिन एक अलग से लेबल किए गए डिलीवरी प्रवेश द्वार का उपयोग करता है। यह इसके गंतव्य पोर्ट के आधार पर नेटवर्क ऑपरेटर के लिए इसके ट्रैफ़िक को पहचानना आसान बनाता है।

IETF का RFC 8484, जो अक्टूबर 2018 में प्रकाशित हुआ था, DoH के HTTPS एक्सचेंज को परिभाषित करता है, जो आमतौर पर पोर्ट 53 पर पारंपरिक DNS के विपरीत पोर्ट 443 का उपयोग करता है।

पारंपरिक DNS, DNS over TLS और DNS over HTTPS की तुलना

सुविधा	पारंपरिक DNS	TLS पर DNS (DoT)	HTTPS पर DNS (DoH)
ट्रांसपोर्ट	UDP या TCP	TLS	HTTPS
सामान्य पोर्ट	53	853	443
स्थानीय नेटवर्क द्वारा पढ़ने योग्य	हाँ	नहीं	नहीं
पोर्ट द्वारा पहचानना आसान	हाँ	हाँ	नहीं, वेब ट्रैफ़िक के साथ पोर्ट 443 साझा करता है
पोर्ट द्वारा ब्लॉक करना आसान	हाँ	हाँ	नहीं, केवल पोर्ट द्वारा चयनात्मक रूप से नहीं
इसमें परिभाषित	मूल DNS विनिर्देशों	TLS विनिर्देश पर DNS	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 over HTTPS नीति दस्तावेज़ रिज़ॉल्वर कॉन्फ़िगरेशन के लिए नियंत्रण प्रदान करता है और यह भी कि क्या उपयोगकर्ता इसे बदल सकते हैं। यह ब्राउज़र के व्यवहार को किसी संगठन के DNS प्रशासन के साथ संरेखित करने का एक व्यावहारिक तरीका है।

वेन्यू या ISP अभी भी गंतव्य पते, कनेक्शन का समय और ट्रैफ़िक वॉल्यूम देख सकता है। अन्य प्रोटोकॉल मेटाडेटा भी किसी साइट की पहचान करने में मदद कर सकता है, इसलिए एक एंक्रिप्टेड DNS प्रश्न अनाम ब्राउज़िंग का वादा नहीं है।

रिज़ॉल्वर को स्वीकृत करने से पहले एक संक्षिप्त विश्वास मूल्यांकन का उपयोग करें:

• ऑपरेटर का नाम तय करें। ब्राउज़र के डिफ़ॉल्ट लेबल पर निर्भर रहने के बजाय यह निर्धारित करें कि कौन सा संगठन प्रश्नों को प्राप्त करता है।
• प्रतिधारण (रिटेंशन) शर्तों को पढ़ें। जांचें कि कौन सी क्वेरी और कनेक्शन जानकारी, कितने समय के लिए और किस उद्देश्य से संग्रहीत की जाती है।
• क्षेत्राधिकार और पहुंच की जांच करें। समझें कि ऑपरेटर जानकारी को कहां प्रोसेस करता है और इसे कौन प्राप्त कर सकता है।
• ज़िम्मेदारी से दृश्यता का मिलान करें। तय करें कि आपकी IT टीम को किन सुरक्षा घटनाओं की जांच करने की आवश्यकता है और किन ब्राउज़िंग विवरणों को उसे बनाए नहीं रखना चाहिए।

उपयोगी प्रश्न यह नहीं है कि अमूर्त रूप से गोपनीयता या प्रबंधनीयता अधिक मायने रखती है या नहीं। यह यह है कि क्या आपका चुना गया DNS पथ उपयोगकर्ताओं को उचित गोपनीयता प्रदान करता है, जबकि संगठन को अपनी घोषित जिम्मेदारियों को पूरा करने में सक्षम बनाता है।

DoH साझा WiFi पर DNS फ़िल्टरिंग को क्यों कमजोर करता है

एक होटल मेहमानों को स्थानीय सेवाओं को खोजने में मदद के लिए रिसेप्शन नंबर देता है। अधिकांश मेहमान डेस्क पर कॉल करते हैं, लेकिन एक अन्य मेहमान इसके बजाय डायरेक्टरी ऐप का उपयोग करता है। रिसेप्शन अपनी खुद की सिफारिशों को नियंत्रित कर सकता है, न कि उस ऐप द्वारा दिए गए उत्तरों को।

नेटवर्क DNS भी इसी तरह काम करता है। आपका नेटवर्क एक रिज़ॉल्वर प्रदान करता है, लेकिन अपने स्वयं के DoH कॉन्फ़िगरेशन वाला ब्राउज़र इसके बजाय किसी बाहरी सेवा से पूछ सकता है।

चित्र नेटवर्क के DNS डेस्क के आसपास के वैकल्पिक मार्ग को दर्शाता है।

बायपास का संबंध रूट से है

समस्या यह नहीं है कि एक एन्क्रिप्टेड क्वेरी को कभी फ़िल्टर नहीं किया जा सकता। समस्या यह है कि आपका फ़िल्टर उस क्वेरी पर नीति लागू नहीं कर सकता जो उसे कभी प्राप्त ही नहीं होती।

पारिवारिक आकर्षण के अतिथि नेटवर्क पर, इसका अर्थ यह हो सकता है कि वयस्क सामग्री ब्लॉक किसी विशेष ब्राउज़र पर लागू नहीं होता है। स्टाफ नेटवर्क पर, एक दुर्भावनापूर्ण एप्लिकेशन किसी अनधिकृत रिज़ॉल्वर के माध्यम से कमांड-एंड-कंट्रोल डोमेन को हल कर सकता है।

परिणाम इस बात पर निर्भर करते हैं कि कौन से नियंत्रण DNS पर निर्भर करते हैं:

• नेटवर्क विशिष्ट नीतियां। SSID या VLAN को सौंपे गए नियम स्वीकृत रिज़ॉल्वर पाथ के बाहर भेजे गए प्रश्नों को नियंत्रित नहीं करेंगे।
• खोज प्रतिबंध। DNS-आधारित Safe Search प्रवर्तन को बायपास किया जा सकता है, हालांकि खाता-स्तर या एंडपॉइंट प्रतिबंध अभी भी लागू हो सकते हैं।
• खतरा अवरोधन। एक DNS फ़िल्टर किसी अनदेखे लुकअप को अस्वीकार नहीं कर सकता, भले ही उसकी खतरा सूची में अनुरोधित डोमेन शामिल हो।

एनक्रिप्टेड-DNS परिनियोजन के एक मापन अध्ययन में Firefox टेलीमेट्री की रिपोर्ट दी गई है, जिसमें 2025 के दौरान 9.54 ट्रिलियन डेस्कटॉप हैंडशेक में से लगभग 13.91% ने DoH का उपयोग किया। यह एक मापन डेटासेट का भी वर्णन करता है जिसमें DoH, DoT की तुलना में लगभग 6.4 गुना अधिक प्रचलित था।

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

केवल हैंडशेक ही नहीं, सत्र (सेशन) को मापें

लगातार बने रहने वाले कनेक्शन क्लाइंट को सेटअप लागत को बाद की क्वेरीज़ में फैलाने की अनुमति देते हैं। मल्टीप्लेक्सिंग इसे प्रत्येक प्रश्न के लिए एक अलग सुरक्षित कनेक्शन स्थापित किए बिना कई एक्सचेंजों को संभालने की अनुमति देती है।

DNS फ़िल्टरिंग अभी भी एक नया कनेक्शन शुरू होने से पहले किसी डोमेन को अस्वीकार कर सकती है, बशर्ते कि अनुरोध फ़िल्टरिंग रिज़ॉल्वर तक पहुँचे। विज्ञापन और ट्रैकर ब्लॉकिंग बाद के अनुरोधों को कम कर सकती है, लेकिन केवल एन्क्रिप्शन विज्ञापनों को नहीं हटाता है या किसी पेज को तेज़ नहीं करता है।

उन परिचालन संकेतों को ट्रैक करें जो वास्तविक समस्याओं को उजागर करते हैं:

• हैंडशेक विफलताएं। कनेक्शन सेटअप त्रुटियों और पुनप्र्यासों (retries) की जांच करें।
• कैश-हिट दरें। कैश्ड उत्तरों को नए रिज़ॉल्यूशन से अलग करें।
• रिसॉल्वर प्रतिक्रिया समय। व्यस्त अतिथि सत्रों के दौरान व्यवहार को मापें।
• फ़ॉलबैक व्यवहार। जांचें कि क्या विफलताएं उपकरणों को रिज़ॉल्यूशन रोकने का कारण बनती हैं या बिना किसी सूचना के दूसरे मार्ग पर स्विच कर देती हैं।

व्यावहारिक नियम: ब्राउज़िंग, नीति प्रवर्तन और विफलता रिकवरी का परीक्षण एक साथ करें, न कि अलग-अलग स्वीकृति जांचों के रूप में।

केवल लेटेंसी मान्यताओं के आधार पर प्रोटोकॉल चुनने की तुलना में एक निकटतम, लचीला रिज़ॉल्वर एंडपॉइंट अधिक बेहतर शुरुआती बिंदु है। वास्तविक लोड के तहत अपने नेटवर्क पर परिणाम की पुष्टि करें।

सामान्य उपकरणों पर DoH को जांचें और बदलें

एक ब्राउज़र सेटिंग यह स्पष्ट कर सकती है कि समान WiFi पर डिवाइस अलग-अलग व्यवहार क्यों करते हैं। रिलीज़ के बीच मेनू लेबल बदलते हैं, इसलिए यदि नीचे दिया गया पाथ दिखाई नहीं देता है तो सेटिंग्स सर्च का उपयोग करें।

ब्राउज़र और ऑपरेटिंग सिस्टम का निरीक्षण करें

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 के लिए नियंत्रण

नियंत्रण	यह क्या रोकता है	यह कहां लागू होता है	ट्रेड-ऑफ
आउटबाउंड पोर्ट 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 कहां लागू किया जा सकता है और कहां केवल नेटवर्क नियंत्रण उपलब्ध हैं।
n
3. सामान्य DNS बायपास मार्गों को बंद करें। जहां आपकी नीति की आवश्यकता हो, आउटबाउंड DoT को ब्लॉक करें और पारंपरिक DNS को स्वीकृत रिज़ॉल्वर तक सीमित करें। दोनों समर्थित नेटवर्क एड्रेस फ़ैमिलीज़ को कवर करें।
4. प्रबंधित ब्राउज़र नीति लागू करें। स्वीकृत DNS पाथ को कॉन्फ़िगर करें और कर्मचारियों के उपकरणों पर असमर्थित उपयोगकर्ता ओवरराइड को रोकें।
5. गेस्ट नेटवर्क रिज़ॉल्वर प्रतिबंध बनाए रखें। ब्लॉक किए गए रिज़ॉल्वर पतों की नियमित रूप से समीक्षा करें, अपवादों का परीक्षण करें और उन नियमों को हटाएं जो अस्वीकार्य संपार्श्विक अवरोधन का कारण बनते हैं।
6. सरल भाषा में गेस्ट नोटिस प्रकाशित करें। समझाएं कि कौन सी श्रेणियों को फ़िल्टर किया गया है, कौन सी नेटवर्क जानकारी रिकॉर्ड की जाती है और एन्क्रिप्टेड DNS या VPN उपयोग पर कोई प्रतिबंध है।
7. हर नेटवर्क पर एक वास्तविक डिवाइस का परीक्षण करें। अनुमति प्राप्त साइटों, ब्लॉक की गई श्रेणियों, स्वीकृत सुरक्षा परीक्षण गंतव्यों, रिज़ॉल्वर की विफलता और VPN व्यवहार की जांच करें।

लॉन्च से पहले: एक ब्लॉक पेज यह साबित करता है कि किसी विशेष अनुरोध को फ़िल्टर किया गया था, न कि यह कि डिवाइस पर मौजूद प्रत्येक एप्लिकेशन उसी मार्ग का पालन करता है।

एन्क्रिप्टेड DNS को स्वीकृति परीक्षण का हिस्सा बनाएं

Shield का उपयोग करने के लिए, आप नेटवर्क के DNS को Shield पर इंगित करते हैं। हम जिस नेटवर्क की रक्षा करते हैं, उस पर हर डिवाइस पर, डिवाइस पर बंद करने के लिए कुछ भी न होने के साथ, हर DNS लुकअप का उत्तर देते हैं; इसलिए बाहरी रिज़ॉल्वर और टनल पथों को नेटवर्क के सुरक्षा डिज़ाइन में शामिल किया जाना चाहिए।

इससे पहले कि आप Purple Shield का परीक्षण करें, हमारे विशेषज्ञ दिखाते हैं कि आपका नेटवर्क VPN और एन्क्रिप्टेड DNS को कैसे संभालता है। उस चर्चा का उपयोग यह स्थापित करने के लिए करें कि कौन से अनुरोध सुरक्षित DNS पथ तक पहुँचते हैं, कौन से नियंत्रण इसे लागू करते हैं, और तब क्या होता है जब कोई डिवाइस किसी अन्य मार्ग का प्रयास करता है।

अतिथि पहुंच बदलने से पहले स्वीकृति मानदंड निर्धारित करें। एक स्वीकृत रिज़ॉल्वर, एक प्रलेखित अपवाद प्रक्रिया और दोहराने योग्य डिवाइस परीक्षण इस धारणा के बजाय अधिक मजबूत आधार प्रदान करते हैं कि एक सक्षम फ़िल्टर सब कुछ देखता है।

---

Purple Shield गेस्ट डिवाइसों पर एजेंटों को इंस्टॉल किए बिना सुरक्षात्मक DNS, कंटेंट फ़िल्टरिंग, थ्रेट डिफ़ेंस और विज्ञापन ब्लॉकिंग प्रदान करता है। अपने SSIDs, फ़िल्टरिंग नीतियों और आपका नेटवर्क एनक्रिप्टेड DNS और VPNs को कैसे संभालता है, इसके बारे में प्री-ट्रायल चर्चा की व्यवस्था करने के लिए Purple Shield पर जाएं।