DNS Over HTTPS (DoH): पब्लिक WiFi फ़िल्टरिंग के लिए निहितार्थ

Purple टेक्निकल ब्रीफिंग में आपका स्वागत है। मैं आज के सत्र के लिए आपका होस्ट हूँ, और हम अगले दस मिनट एक ऐसे विषय पर बिताने जा रहे हैं जो अभी हजारों पब्लिक WiFi डिप्लॉयमेंट में कंटेंट फ़िल्टरिंग नीतियों को चुपचाप कमजोर कर रहा है — DNS over HTTPS, या DoH। यदि आप किसी होटल, रिटेल एस्टेट, स्टेडियम, या सार्वजनिक क्षेत्र की सुविधा में गेस्ट WiFi चला रहे हैं, और आपने अपने नेटवर्क आर्किटेक्चर में विशेष रूप से DoH को संबोधित नहीं किया है, तो इस बात की पूरी संभावना है कि आपकी फ़िल्टरिंग नीति में एक महत्वपूर्ण अंतर है। आइए जानें कि वास्तव में वह अंतर क्या है, यह क्यों मायने रखता है, और आप इसके बारे में क्या कर सकते हैं। सेक्शन एक — संदर्भ और समस्या विवरण। आइए पारंपरिक DNS फ़िल्टरिंग कैसे काम करती है, इसके त्वरित विवरण के साथ शुरू करें, क्योंकि बायपास तंत्र को समझने के लिए यह समझना आवश्यक है कि किसे बायपास किया जा रहा है। जब कोई गेस्ट डिवाइस आपके WiFi से जुड़ता है और किसी वेबसाइट पर जाने का प्रयास करता है, तो सबसे पहले वह एक DNS क्वेरी भेजता है — मूल रूप से यह पूछता है कि इस डोमेन का IP पता क्या है? वह क्वेरी पोर्ट 53 पर UDP या TCP पर यात्रा करती है। आपका नेटवर्क इंफ्रास्ट्रक्चर उस क्वेरी को इंटरसेप्ट करता है, इसे आपके चुने हुए DNS रिज़ॉल्वर पर रूट करता है, और वह रिज़ॉल्वर आपकी फ़िल्टरिंग नीति के खिलाफ डोमेन की जांच करता है। यदि डोमेन ब्लॉकलिस्ट में है — मैलवेयर, वयस्क कंटेंट, जुआ, जो भी आपकी स्वीकार्य उपयोग नीति निर्दिष्ट करती है — तो रिज़ॉल्वर IP पता वापस करने से इनकार कर देता है, और कनेक्शन कभी नहीं होता है। यह प्रत्येक DNS-आधारित कंटेंट फ़िल्टरिंग डिप्लॉयमेंट की नींव है। यह लागत प्रभावी है, यह थ्रूपुट को प्रभावित नहीं करता है, और यह लगभग एक दशक से वेन्यू ऑपरेटरों के लिए मानक दृष्टिकोण रहा है। DNS over HTTPS इस मॉडल को तोड़ता है। यहाँ बताया गया है कि कैसे। DoH पोर्ट 443 पर मानक HTTPS ट्रैफ़िक के भीतर DNS क्वेरीज़ को रैप करता है। आपके नेटवर्क के दृष्टिकोण से, यह किसी भी अन्य एन्क्रिप्टेड वेब ट्रैफ़िक के समान दिखता है। DoH क्वेरी और वेबपेज लोड करने वाले, वीडियो स्ट्रीम करने वाले, या बैंकिंग ऐप का उपयोग करने वाले उपयोगकर्ता के बीच अंतर करने का कोई तरीका नहीं है। क्वेरी सीधे एक बाहरी DoH रिज़ॉल्वर — Google का 8.8.8.8, Cloudflare का 1.1.1.1, या कई अन्य — पर एक एन्क्रिप्टेड चैनल के माध्यम से जाती है जिसे आपका DNS फ़िल्टर निरीक्षण नहीं कर सकता है। परिणाम? आपकी सावधानीपूर्वक कॉन्फ़िगर की गई DNS फ़िल्टरिंग नीति पूरी तरह से बायपास हो जाती है। डिवाइस आपके रिज़ॉल्वर द्वारा क्वेरी को देखे बिना सीधे डोमेन को रिज़ॉल्व करता है। अब, यह आपके मेहमानों द्वारा किया गया कोई जानबूझकर किया गया हमला नहीं है। अधिकांश मामलों में, यह पूरी तरह से निष्क्रिय है। Firefox में 2020 से डिफ़ॉल्ट रूप से DoH सक्षम है। यदि कॉन्फ़िगर किया गया रिज़ॉल्वर इसका समर्थन करता है, तो Chrome DNS क्वेरीज़ को DoH में ऑटो-अपग्रेड करता है। Android 9 और उससे ऊपर के संस्करण डिफ़ॉल्ट रूप से DNS over TLS के साथ Private DNS का समर्थन करते हैं। iOS ने iOS 14 से DoH कॉन्फ़िगरेशन प्रोफ़ाइल का समर्थन किया है। ये मुख्यधारा के उपभोक्ता उपकरण हैं जो वही कर रहे हैं जो उनके निर्माताओं ने चाहा था। आपके मेहमान आपकी फ़िल्टरिंग को बायपास करने की कोशिश नहीं कर रहे हैं। उनके उपकरण बस इसे स्वचालित रूप से कर रहे हैं। सेक्शन दो — तकनीकी डीप डाइव। आइए मैकेनिक्स में प्रवेश करें। क्षेत्र में आपको दो प्राथमिक DoH इम्प्लीमेंटेशन पैटर्न मिलेंगे। पहला एप्लीकेशन-लेवल DoH है, जहां एप्लीकेशन — आमतौर पर एक ब्राउज़र — ऑपरेटिंग सिस्टम की DNS सेटिंग्स से स्वतंत्र रूप से अपना DoH कॉन्फ़िगरेशन बनाए रखता है। Firefox इसका प्रमुख उदाहरण है। जब Firefox इंस्टॉल होता है और DoH सक्षम होता है, तो यह सिस्टम DNS रिज़ॉल्वर को पूरी तरह से अनदेखा कर देता है और अपनी सभी DNS क्वेरीज़ को अपने कॉन्फ़िगर किए गए DoH प्रदाता को भेजता है, जो डिफ़ॉल्ट रूप से Cloudflare है। आपका DHCP-असाइन किया गया DNS सर्वर अप्रासंगिक है। आपके पोर्ट 53 इंटरसेप्शन नियम अप्रासंगिक हैं। Firefox पोर्ट 443 पर पूरी तरह से अलग DNS बातचीत कर रहा है जिसे आप देख नहीं सकते। दूसरा पैटर्न OS-लेवल DoH है, जहां ऑपरेटिंग सिस्टम खुद अपग्रेड को संभालता है। Chrome और Windows 10 और 11 यह दृष्टिकोण अपनाते हैं। वे जांचते हैं कि क्या सिस्टम का कॉन्फ़िगर किया गया DNS रिज़ॉल्वर — जो आपके DHCP सर्वर द्वारा असाइन किया गया है — के पास एक संबंधित DoH एंडपॉइंट है। यदि ऐसा है, तो वे स्वचालित रूप से DoH में अपग्रेड हो जाते हैं। इसे अपॉर्चुनिस्टिक DoH कहा जाता है। यदि आप अपने गेस्ट DNS सर्वर के रूप में 8.8.8.8 असाइन कर रहे हैं, तो Chrome स्वचालित रूप से Google के DoH एंडपॉइंट का उपयोग करेगा। यदि आप 1.1.1.1 असाइन कर रहे हैं, तो यह Cloudflare के DoH एंडपॉइंट का उपयोग करेगा। यह अंतर आपकी शमन रणनीति के लिए मायने रखता है, जिस पर हम जल्द ही आएंगे। एक तीसरा वेक्टर भी उल्लेखनीय है: DNS over TLS, या DoT। यह पोर्ट 853 पर काम करता है और DNS क्वेरीज़ को HTTPS में रैप करने के बजाय TLS का उपयोग करके एन्क्रिप्ट करता है। DoH की तुलना में इसे ब्लॉक करना आसान है क्योंकि यह एक समर्पित पोर्ट का उपयोग करता है, लेकिन यह Private DNS सक्षम वाले Android उपकरणों पर तेजी से आम हो रहा है। आपकी शमन रणनीति को दोनों को संबोधित करने की आवश्यकता है। अब बात करते हैं कि यह केवल एक तकनीकी जिज्ञासा नहीं, बल्कि एक अनुपालन और परिचालन जोखिम क्यों है। GDPR के तहत, यदि आपकी स्वीकार्य उपयोग नीति में कहा गया है कि आप कंटेंट की कुछ श्रेणियों को फ़िल्टर करते हैं, और आपके तकनीकी नियंत्रण वास्तव में उस नीति को लागू नहीं करते हैं, तो आपके पास अपनी घोषित डेटा सुरक्षा और कंटेंट गवर्नेंस प्रतिबद्धताओं और आपके वास्तविक तकनीकी कार्यान्वयन के बीच एक अंतर है। यदि आपको कभी नियामक जांच या किसी घटना का सामना करना पड़ता है तो यह एक बचाव की समस्या है। यूके के ऑनलाइन सुरक्षा अधिनियम के तहत, सार्वजनिक इंटरनेट एक्सेस प्रदान करने वाले वेन्यू ऑपरेटरों के पास उपयोगकर्ताओं — विशेष रूप से नाबालिगों — को हानिकारक कंटेंट से बचाने के दायित्व हैं। यदि DoH चुपचाप आपकी कंटेंट फ़िल्टरिंग को बायपास कर रहा है, तो हो सकता है कि आप उन दायित्वों को पूरा न कर रहे हों। उन वेन्यू के लिए जो PCI DSS दायरे में आते हैं — विशेष रूप से वे जहां भुगतान कार्ड डेटा गेस्ट WiFi के आस-पास के नेटवर्क पर प्रवाहित होता है — PCI DSS संस्करण 4.0 की आवश्यकता है कि आप अपने नेटवर्क सुरक्षा नियंत्रणों के हिस्से के रूप में DNS ट्रैफ़िक की निगरानी और नियंत्रण करें। अनियंत्रित DoH ट्रैफ़िक उस नियंत्रण ढांचे में एक अंतर है। और विशुद्ध सुरक्षा के दृष्टिकोण से, मैलवेयर द्वारा DoH का सक्रिय रूप से शोषण किया गया है। थ्रेट एक्टर्स ने DoH का उपयोग कमांड-एंड-कंट्रोल चैनल के रूप में किया है क्योंकि यह सामान्य HTTPS ट्रैफ़िक में मिल जाता है। GodLua बैकडोर ने कमांड-एंड-कंट्रोल संचार के लिए DoH का उपयोग किया। PsiXBot मैलवेयर ने Google की DoH सेवा का उपयोग किया। यदि आपकी सुरक्षा निगरानी दुर्भावनापूर्ण गतिविधि का पता लगाने के लिए DNS विज़िबिलिटी पर निर्भर करती है, तो DoH ब्लाइंड स्पॉट एक वास्तविक खतरा हैं। सेक्शन तीन — इम्प्लीमेंटेशन सिफारिशें। ठीक है, आइए व्यावहारिक बनें। तीन प्राथमिक शमन रणनीतियाँ हैं, और अधिकांश वेन्यू डिप्लॉयमेंट में, आप तीनों को मिलाकर लागू करना चाहेंगे। रणनीति एक: फ़ायरवॉल पर ज्ञात DoH रिज़ॉल्वर एंडपॉइंट्स को ब्लॉक करें। यह आपकी सुरक्षा की पहली पंक्ति है और सबसे तुरंत तैनात करने योग्य विकल्प है। ज्ञात DoH रिज़ॉल्वर IP पतों और डोमेन — Google, Cloudflare, Quad9, NextDNS, AdGuard, और अन्य — की एक ब्लॉकलिस्ट बनाए रखें और अपने गेस्ट VLAN से उन एंडपॉइंट्स के लिए आउटबाउंड HTTPS ट्रैफ़िक को अस्वीकार करें। IETF और विभिन्न सुरक्षा विक्रेता इन सूचियों को प्रकाशित और बनाए रखते हैं। GitHub पर curl प्रोजेक्ट ज्ञात DoH रिज़ॉल्वर की एक व्यापक सूची बनाए रखता है जो एक अच्छा प्रारंभिक बिंदु है। यह दृष्टिकोण अधिकांश DoH ट्रैफ़िक को संभालता है क्योंकि, जैसा कि कार्नेगी मेलन के सॉफ्टवेयर इंजीनियरिंग संस्थान के शोध से पता चला है, अधिकांश DoH ट्रैफ़िक कुछ प्रसिद्ध रिज़ॉल्वर पर जाता है। जो उपयोगकर्ता कस्टम DoH रिज़ॉल्वर को कॉन्फ़िगर करने के लिए DNS के बारे में पर्याप्त जानते हैं, वे बहुत कम अल्पसंख्यक हैं। इस दृष्टिकोण की सीमा यह है कि यह एक ब्लॉकलिस्ट है, और ब्लॉकलिस्ट को रखरखाव की आवश्यकता होती है। नए DoH रिज़ॉल्वर नियमित रूप से दिखाई देते हैं। लेकिन अन्य रणनीतियों के साथ मिलकर, यह ठोस कवरेज प्रदान करता है। रणनीति दो: आपके नेक्स्ट-जनरेशन फ़ायरवॉल पर TLS निरीक्षण। Palo Alto Networks, Fortinet, Check Point, और Cisco Firepower सहित विक्रेताओं के नेक्स्ट-जनरेशन फ़ायरवॉल TLS निरीक्षण का समर्थन करते हैं — जिसे SSL निरीक्षण या डीप पैकेट निरीक्षण भी कहा जाता है। सक्षम होने पर, फ़ायरवॉल HTTPS ट्रैफ़िक के लिए मैन-इन-द-मिडल के रूप में कार्य करता है, इसे डिक्रिप्ट करता है, पेलोड का निरीक्षण करता है, और अग्रेषित करने से पहले इसे फिर से एन्क्रिप्ट करता है। यह फ़ायरवॉल को DoH ट्रैफ़िक की पहचान करने की अनुमति देता है, भले ही वह किसी अज्ञात रिज़ॉल्वर पर जा रहा हो। मुख्य कॉन्फ़िगरेशन कदम यह सुनिश्चित करना है कि आपका गेस्ट VLAN ट्रैफ़िक निरीक्षण नीति के माध्यम से रूट किया गया है। यहाँ परिचालन संबंधी विचार प्रमाणपत्र ट्रस्ट है। गेस्ट उपकरणों पर TLS निरीक्षण काम करने के लिए, उन उपकरणों को आपके निरीक्षण प्रमाणपत्र पर भरोसा करना होगा। प्रबंधित कॉर्पोरेट उपकरणों पर, यह सीधा है — आप MDM के माध्यम से प्रमाणपत्र पुश करते हैं। अप्रबंधित गेस्ट उपकरणों पर, यह अधिक जटिल है। गेस्ट WiFi के लिए व्यावहारिक दृष्टिकोण कैप्टिव पोर्टल स्वीकृति प्रवाह का उपयोग करके उपयोगकर्ताओं को सूचित करना है कि कंटेंट फ़िल्टरिंग उद्देश्यों के लिए ट्रैफ़िक का निरीक्षण किया जा सकता है, और अपने प्राथमिक नियंत्रणों के रूप में DoH रिज़ॉल्वर ब्लॉकिंग और DNS इंटरसेप्शन के संयोजन पर भरोसा करना है, जिसमें उच्च जोखिम वाले वातावरण के लिए एक माध्यमिक परत के रूप में TLS निरीक्षण शामिल है। रणनीति तीन: जबरन DNS इंटरसेप्शन और रीडायरेक्ट। UDP और TCP पोर्ट 53 पर सभी आउटबाउंड DNS ट्रैफ़िक को इंटरसेप्ट करने और इसे अपने अनुपालन करने वाले DNS रिज़ॉल्वर पर रीडायरेक्ट करने के लिए अपने फ़ायरवॉल या वायरलेस कंट्रोलर को कॉन्फ़िगर करें। यह DoH को नहीं रोकता है, लेकिन यह सुनिश्चित करता है कि कोई भी DNS ट्रैफ़िक जो पोर्ट 53 पर वापस आता है — क्योंकि DoH विफल हो गया या उपलब्ध नहीं था — कैप्चर और फ़िल्टर किया जाए। DNS over TLS को आपके नियंत्रणों को बायपास करने से रोकने के लिए गेस्ट VLAN से आउटबाउंड पोर्ट 853 को ब्लॉक करने के साथ इसे मिलाएं। प्रबंधित एंडपॉइंट्स — कॉर्पोरेट उपकरणों, स्टाफ उपकरणों — के लिए आपके पास एक अतिरिक्त विकल्प है: ब्राउज़र और OS स्तर पर DoH को अक्षम करने के लिए समूह नीति या MDM कॉन्फ़िगरेशन। Firefox में, network.trr.mode वरीयता को 5 पर सेट करने से DoH पूरी तरह से अक्षम हो जाता है। Chrome में, disable-features equals DnsOverHttps फ़्लैग भी यही प्राप्त करता है। Windows 10 और 11 में DoH व्यवहार को नियंत्रित करने के लिए समूह नीति सेटिंग्स हैं। यह प्रबंधित उपकरणों के लिए सबसे विश्वसनीय नियंत्रण है, लेकिन यह अप्रबंधित गेस्ट उपकरणों पर लागू नहीं होता है। सेक्शन चार — इम्प्लीमेंटेशन की कमियां। कुछ चीजें जो आमतौर पर क्षेत्र में गलत हो जाती हैं। सबसे लगातार विफलता मोड अपूर्ण पोर्ट 53 इंटरसेप्शन है। टीमें अपनी DNS फ़िल्टरिंग सेवा को सही ढंग से कॉन्फ़िगर करती हैं लेकिन फ़ायरवॉल नियम जोड़ना भूल जाती हैं जो सभी आउटबाउंड पोर्ट 53 ट्रैफ़िक को रीडायरेक्ट करता है। हार्डकोडेड DNS सेटिंग्स — 8.8.8.8, 1.1.1.1 — वाले डिवाइस फ़िल्टर को पूरी तरह से बायपास कर देते हैं। हमेशा सत्यापित करें कि यह नियम लागू है और एक हार्डकोडेड DNS सर्वर के साथ एक परीक्षण डिवाइस को कॉन्फ़िगर करके और यह पुष्टि करके इसका परीक्षण करें कि फ़िल्टर किए गए डोमेन अभी भी ब्लॉक हैं। दूसरी आम विफलता IPv6 का ध्यान न रखना है। IPv6 पर DNS क्वेरीज़ तेजी से आम हो रही हैं, और कई फ़ायरवॉल नियम केवल IPv4 के लिए लिखे गए हैं। सुनिश्चित करें कि आपके पोर्ट 53 इंटरसेप्शन और DoH रिज़ॉल्वर ब्लॉकलिस्ट दोनों IPv4 और IPv6 पतों को कवर करते हैं। तीसरा: पुरानी DoH रिज़ॉल्वर ब्लॉकलिस्ट। यदि आप DoH रिज़ॉल्वर IPs की एक स्टैटिक ब्लॉकलिस्ट बनाए रख रहे हैं, तो यह पुरानी हो जाएगी। अपडेट प्रक्रिया को स्वचालित करें या एक DNS फ़िल्टरिंग सेवा का उपयोग करें जो आपके लिए इस सूची को बनाए रखती है। Cloudflare Gateway, Cisco Umbrella, और इसी तरह की एंटरप्राइज़ DNS सेवाएं एक प्रबंधित क्षमता के रूप में DoH बायपास डिटेक्शन शामिल करती हैं। चौथा: एकल शमन परत पर अत्यधिक निर्भरता। DoH शमन एक डिफेंस-इन-डेप्थ समस्या है। कोई भी एकल नियंत्रण पर्याप्त नहीं है। ज्ञात रिज़ॉल्वर को ब्लॉक करना अधिकांश मामलों को संभालता है। TLS निरीक्षण किनारे के मामलों को संभालता है। DNS इंटरसेप्शन एक सुरक्षा जाल प्रदान करता है। तीनों को परत दर परत लागू करें। सेक्शन पांच — रैपिड-फायर प्रश्न। क्या DoH शमन वैध गोपनीयता उपकरणों को खराब करता है? संभावित रूप से, हाँ। यदि कोई उपयोगकर्ता वैध गोपनीयता-केंद्रित ब्राउज़र कॉन्फ़िगरेशन चला रहा है, तो आपकी DoH ब्लॉकिंग उन्हें आपके DNS रिज़ॉल्वर का उपयोग करने के लिए मजबूर करेगी। आपकी स्वीकार्य उपयोग नीति में यह स्पष्ट होना चाहिए कि वेन्यू के DNS रिज़ॉल्वर का उपयोग कंटेंट फ़िल्टरिंग उद्देश्यों के लिए किया जाता है। यह मानक अभ्यास है और कानूनी रूप से सुरक्षित है। क्या DoH का उपयोग मेरे नेटवर्क से डेटा निकालने के लिए किया जा सकता है? हाँ, और यह एक वास्तविक थ्रेट वेक्टर है। DoH पर DNS टनलिंग को वास्तविक दुनिया में प्रदर्शित किया गया है। आपके नेक्स्ट-जनरेशन फ़ायरवॉल की DoH पहचान क्षमता में असामान्य रूप से उच्च क्वेरी वॉल्यूम या टनलिंग के अनुरूप क्वेरी पैटर्न के लिए विसंगति का पता लगाना शामिल होना चाहिए। उन मोबाइल ऐप्स के बारे में क्या जो DoH का उपयोग करते हैं? यह सबसे कठिन मामला है। मोबाइल ऐप्स जो अपने स्वयं के DoH स्टैक को लागू करते हैं — OS DNS सेटिंग्स का उपयोग करने के बजाय — उन्हें TLS निरीक्षण के बिना नियंत्रित करना कठिन है। आपका सबसे अच्छा शमन ज्ञात रिज़ॉल्वर ब्लॉकिंग और TLS निरीक्षण का संयोजन है। Is WPA3 relevant here? WPA3 improves over-the-air encryption and provides forward secrecy, which is excellent for guest privacy. But WPA3 doesn't address DoH — that's a layer 7 application protocol issue, not a layer 2 wireless security issue. They're complementary controls addressing different threat vectors. सेक्शन छह — ROI और व्यावसायिक प्रभाव। आइए इसे ठीक से संबोधित करने के व्यावसायिक मामले के साथ समाप्त करें। DoH को संबोधित न करने की लागत असममित है। एक एकल घटना — आपके नेटवर्क पर अवैध कंटेंट तक पहुँचने वाला कोई गेस्ट, एक मैलवेयर कॉलबैक जो अनपेक्षित रह जाता है क्योंकि आपकी DNS मॉनिटरिंग में एक ब्लाइंड स्पॉट था, आपकी कंटेंट फ़िल्टरिंग अनुपालन के बारे में एक नियामक जांच — उचित शमन में निवेश की तुलना में काफी अधिक लागत ला सकती है। 20 संपत्तियों में काम करने वाले एक होटल समूह के लिए, DoH शमन को तैनात करने में आमतौर पर फ़ायरवॉल नियमों और DNS इंटरसेप्शन कॉन्फ़िगरेशन के लिए प्रति संपत्ति दो से चार घंटे का एकमुश्त कॉन्फ़िगरेशन प्रयास शामिल होता, साथ ही रिज़ॉल्वर ब्लॉकलिस्ट बनाए रखने का एक निरंतर परिचालन ओवरहेड होता है — जो काफी हद तक स्वचालित होता है यदि आप एक प्रबंधित DNS फ़िल्टरिंग सेवा का उपयोग कर रहे हैं। जोखिम में कमी की तुलना में कुल निवेश मामूली है। PCI DSS के तहत काम करने वाली रिटेल श्रृंखलाओं के लिए, अनुपालन लाभ सीधे मात्रात्मक है। यह प्रदर्शित करना कि आपके नेटवर्क सुरक्षा नियंत्रणों में DoH शमन शामिल है, PCI DSS ऑडिट निष्कर्ष और संबंधित सुधारात्मक लागतों के जोखिम को कम करता है। सार्वजनिक क्षेत्र के स्थानों और ऑनलाइन सुरक्षा अधिनियम के तहत काम करने वालों के लिए, प्रलेखित DoH शमन आपके साक्ष्य आधार का हिस्सा है कि आपने अपनी कंटेंट फ़िल्टरिंग नीति को लागू करने के लिए उचित तकनीकी कदम उठाए हैं। मुख्य बात: DoH भविष्य की समस्या नहीं है। यह वर्तमान की समस्या है। Firefox, Chrome, Android, और iOS सभी अभी आपके मेहमानों के उपकरणों पर DoH-सक्षम कॉन्फ़िगरेशन भेज रहे हैं। यदि आपने पिछले 12 महीनों में DoH बायपास वेक्टर्स के लिए अपने DNS फ़िल्टरिंग आर्किटेक्चर का ऑडिट नहीं किया है, तो वह ऑडिट आपके निकट-अवधि के रोडमैप पर होना चाहिए। आज की ब्रीफिंग से मुख्य निष्कर्षों को संक्षेप में प्रस्तुत करने के लिए। एक: DoH पोर्ट 443 पर HTTPS के भीतर DNS क्वेरीज़ को एन्क्रिप्ट करता है, जिससे वे पारंपरिक पोर्ट 53 DNS फ़िल्टरिंग के लिए अदृश्य हो जाते हैं। यह मुख्यधारा के ब्राउज़रों और ऑपरेटिंग सिस्टम पर डिफ़ॉल्ट रूप से हो रहा है। दो: तीन-स्तरीय शमन रणनीति — ज्ञात DoH रिज़ॉल्वर IPs को ब्लॉक करना, अपने नेक्स्ट-जनरेशन फ़ायरवॉल पर TLS निरीक्षण लागू करना, और पोर्ट 53 इंटरसेप्शन लागू करना — प्रबंधित और अप्रबंधित दोनों गेस्ट उपकरणों के लिए डिफेंस-इन-डेप्थ कवरेज प्रदान करती है। तीन: यह एक अनुपालन मुद्दा है, न कि केवल एक तकनीकी मुद्दा। GDPR, ऑनलाइन सुरक्षा अधिनियम, और PCI DSS सभी के उन वेन्यू के लिए निहितार्थ हैं जहां DoH चुपचाप कंटेंट फ़िल्टरिंग नीतियों को बायपास कर रहा है। चार: सबसे आम कार्यान्वयन विफलता अपूर्ण पोर्ट 53 इंटरसेप्शन है। इसका परीक्षण करें। इसे सत्यापित करें। यह न मानें कि यह काम कर रहा है। पांच: प्रबंधित DNS फ़िल्टरिंग सेवाएं — Cloudflare Gateway, Cisco Umbrella, और इसी तरह की — तेजी से एक प्रबंधित क्षमता के रूप में DoH बायपास डिटेक्शन को शामिल करती हैं, जो स्टैटिक ब्लॉकलिस्ट बनाए रखने के परिचालन ओवरहेड को कम करती है। आज की Purple टेक्निकल ब्रीफिंग के लिए बस इतना ही। यदि आप अपने वर्तमान DNS फ़िल्टरिंग आर्किटेक्चर का ऑडिट करना चाहते हैं या अपने वेन्यू एस्टेट में DoH शमन लागू करना चाहते हैं, तो Purple प्लेटफ़ॉर्म उस डिप्लॉयमेंट का समर्थन करने के लिए नेटवर्क इंटेलिजेंस और गेस्ट WiFi प्रबंधन लेयर प्रदान करता है। सुनने के लिए धन्यवाद, और हम आपसे अगले सत्र में मिलेंगे।