DNS over HTTPS बनाम Enterprise Split-Horizon DNS: एक ऐसा गतिरोध जो अपने आप नहीं सुलझेगा

इंटरनेट के ज़्यादातर इतिहास में, DNS क्वेरीज़ पोर्ट 53 पर क्लियरटेक्स्ट (cleartext) में यात्रा करती थीं। नेटवर्क पाथ पर मौजूद कोई भी व्यक्ति उन्हें पढ़ सकता था, लॉग कर सकता था और उनमें बदलाव कर सकता था। यह प्राइवेसी की एक बड़ी समस्या थी जिसे IETF ने आखिरकार दो एन्क्रिप्टेड विकल्पों के साथ सुलझाया: 2016 में DNS over TLS (DoT, RFC 7858) और 2018 में DNS over HTTPS (DoH, RFC 8484)।

विशेष रूप से DoH ने गेम को पूरी तरह से बदल दिया, क्योंकि यह DNS को एक नियमित HTTPS स्ट्रीम के अंदर छिपा देता है। नेटवर्क पर नज़र रखने वाले (network observer) के लिए, एक DoH क्वेरी कंटेंट सर्वर से जुड़े किसी भी अन्य TLS कनेक्शन के समान ही दिखती है। यह किसी असुरक्षित कॉफ़ी-शॉप नेटवर्क पर ब्राउज़ करने वाले यूज़र्स के लिए बहुत बढ़िया है। लेकिन यह उस कॉर्पोरेट IT टीम के लिए बिल्कुल भी अच्छा नहीं है जो नेटवर्क पेरिमीटर को पार करने वाली हर DNS क्वेरी को देखने—और निर्देशित (steer) करने—पर निर्भर करती है।

यही वह गतिरोध (standoff) है। दोनों पक्षों की अपनी वैध और स्पष्ट आवश्यकताएं हैं। मानक निकायों (standards bodies), ब्राउज़र वेंडर्स और ऑपरेटिंग सिस्टम वेंडर्स ने दशक का एक बड़ा हिस्सा इन दोनों को एक साथ काम करने योग्य बनाने की कोशिश में बिताया है, और इसका नतीजा कुछ ऐसे असहज समझौते (uneasy compromises) हैं जिन्हें 2026 में किसी भी एंटरप्राइज़ नेटवर्क को चलाने वाले व्यक्ति को समझना आवश्यक है।

DoH वास्तव में क्या करता है

एक DoH क्लाइंट DNS क्वेरीज़ को HTTPS POST या GET रिक्वेस्ट के रूप में भेजता है, जो आमतौर पर https://dns.google/dns-query, https://cloudflare-dns.com/dns-query, या किसी अन्य पब्लिक रिज़ॉल्वर को भेजी जाती हैं। प्रतिक्रिया (response) एक सामान्य HTTPS रिस्पॉन्स बॉडी के रूप में वापस आती है। यहाँ तीन महत्वपूर्ण विशेषताएँ मायने रखती हैं:

ट्रांज़िट में एन्क्रिप्टेड (Encrypted in transit)। नेटवर्क ऑब्ज़र्वर क्वेरी का नाम या उसका उत्तर नहीं पढ़ सकते।
प्रमाणित सर्वर (Authenticated server)। क्लाइंट रिज़ॉल्वर के TLS सर्टिफ़िकेट को वेरिफ़ाई करता है, जिससे कोई 'मैन-इन-द-मिडल' (man-in-the-middle) इसका रूप धारण नहीं कर सकता।
वेब ट्रैफ़िक से अप्रभेद्य (Indistinguishable from web traffic)। पोर्ट 443, TLS 1.3, सामान्य SNI पैटर्न। इसमें फ़िल्टर करने के लिए DNS जैसा कोई अलग ट्रैफ़िक नहीं होता है।

तीसरी विशेषता ही वह है जो इस टकराव को जन्म देती है। DoT भी क्वेरीज़ को एन्क्रिप्ट करता है, लेकिन यह एक समर्पित (dedicated) पोर्ट (853) पर ऐसा करता है, जिसे नेटवर्क आसानी से ब्लॉक या रीडायरेक्ट कर सकता है। साधारण वेब ब्राउज़िंग को ब्लॉक किए बिना DoH को चुनिंदा रूप से (selectively) ब्लॉक नहीं किया जा सकता।

एंटरप्राइज़ स्प्लिट-होराइज़न DNS वास्तव में क्या करता है

ज़्यादातर बड़े संगठन स्प्लिट-होराइज़न DNS (split-horizon DNS) का इस्तेमाल करते हैं। इसमें एक ही नाम (vpn.example.corp, git.example.com, intranet.example.com) अलग-अलग IP एड्रेस में रिज़ॉल्व होता है, जो इस बात पर निर्भर करता है कि क्वेरी नेटवर्क के अंदर से आ रही है या बाहर से।

नेटवर्क के अंदर:

रिज़ॉल्वर कंपनी का इंटरनल DNS होता है, जो अक्सर Active Directory से जुड़ा होता है।
git.example.com शायद 10.0.4.7 जैसे प्राइवेट RFC 1918 एड्रेस में रिज़ॉल्व हो।
केवल-आंतरिक (Internal-only) ज़ोन (example.corp, example.internal) पब्लिक इंटरनेट पर मौजूद ही नहीं होते।
DLP और सिक्योरिटी टूल्स हर क्वेरी को देखते हैं और ज्ञात ख़राब (known-bad) डोमेन वाले DNS को फ़्लैग कर सकते हैं।

नेटवर्क के बाहर (या घर के Wi-Fi पर मौजूद किसी निजी डिवाइस पर):

वही क्वेरी एक पब्लिक रिज़ॉल्वर के पास जाती है।
git.example.com पब्लिक लोड बैलेंसर में रिज़ॉल्व होता है।
केवल-आंतरिक नाम रिज़ॉल्व ही नहीं होते।

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

DoH इस धारणा को तोड़ देता है। यदि ब्राउज़र अपना ख़ुद का रिज़ॉल्वर साथ लाता है, या ऑपरेटिंग सिस्टम, सिस्टम रिज़ॉल्वर को बायपास कर देता है, तो एंडपॉइंट इंटरनल DNS से संपर्क करना पूरी तरह से बंद कर देता है। इंटरनल होस्टनेम रिज़ॉल्व होना बंद हो जाते हैं। सिक्योरिटी टूल्स उन क्वेरीज़ को देखना बंद कर देते हैं जिन पर वे ख़तरों का पता लगाने के लिए निर्भर होते हैं।

ब्राउज़र और OS ने इसे संभालने की कैसे कोशिश की है

वेंडर्स इस समस्या से अनजान नहीं हैं। आज जो समझौते (compromises) मौजूद हैं वे कई स्तरों वाले (layered) और थोड़े तदर्थ (ad hoc) हैं।

Chrome का "ऑटोमैटिक अपग्रेड" मॉडल

Chrome का DoH इम्प्लीमेंटेशन सिस्टम रिज़ॉल्वर को केवल तभी DoH में अपग्रेड करता है, जब सिस्टम रिज़ॉल्वर ख़ुद Chrome की DoH-सक्षम प्रोवाइडर्स (Google, Cloudflare, Quad9, आदि) की अलाउ-लिस्ट (allowlist) में शामिल हो। यदि सिस्टम को किसी ऐसे इंटरनल कॉर्पोरेट रिज़ॉल्वर का उपयोग करने के लिए कॉन्फ़िगर किया गया है जो अलाउ-लिस्ट में नहीं है, तो Chrome उसमें कोई बदलाव नहीं करता। एंटरप्राइज़ पॉलिसियां Chrome की DnsOverHttpsMode सेटिंग के ज़रिए DoH को पूरी तरह से डिसेबल भी कर सकती हैं।

Firefox का TRR (Trusted Recursive Resolver) मॉडल

Firefox का दृष्टिकोण ज़्यादा विवादित रहा है। जिन स्थानों (locales) में Mozilla ने DoH को डिफ़ॉल्ट रूप से सक्षम किया है, वहां Firefox डिफ़ॉल्ट रिज़ॉल्वर (जैसे अमेरिका में Cloudflare) का उपयोग करता है, लेकिन यह DoH को इनेबल करने से पहले एंटरप्राइज़ और नेटवर्क ह्यूरिस्टिक्स (heuristics) भी चलाता है। एक महत्वपूर्ण सिग्नल कैनरी डोमेन (canary domain) use-application-dns.net है: जब लोकल रिज़ॉल्वर एक नकारात्मक परिणाम देता है, तो Firefox उन यूज़र्स के लिए एप्लिकेशन-लेवल DNS को डिसेबल कर देता है जिनका DoH डिफ़ॉल्ट रूप से इनेबल था। Mozilla एक महत्वपूर्ण स्प्लिट-होराइज़न बारीकी (nuance) का भी दस्तावेज़ीकरण करता है: यदि DoH रिज़ॉल्यूशन विफल हो जाता है तो केवल-आंतरिक नाम साधारण DNS पर वापस (fall back) आ सकते हैं, लेकिन नेटवर्क के अंदर अलग तरह से रिज़ॉल्व होने वाले पब्लिक नामों के लिए DoH को डिसेबल करने हेतु एंटरप्राइज़ पॉलिसी की आवश्यकता होती है।

Apple का एन्क्रिप्टेड DNS (iOS 14+, macOS Big Sur+)

Apple ऐप्स और कॉन्फ़िगरेशन प्रोफ़ाइल को पूरे सिस्टम के लिए DoH या DoT में ऑप्ट-इन करने की अनुमति देता है, लेकिन MDM पॉलिसियों का भी सम्मान करता है जो एक विशिष्ट रिज़ॉल्वर को अनिवार्य बनाती हैं। एंटरप्राइज़-मैनेज्ड डिवाइस बिना किसी अतिरिक्त सेटिंग के सही ढंग से व्यवहार करते हैं (behave correctly out of the box)।

Windows नेटिव DoH

Windows 11 और Windows Server 2022 और उसके बाद के वर्ज़न में, OS स्वयं सिस्टम रिज़ॉल्वर के लिए DoH का उपयोग कर सकता है। ग्रुप पॉलिसी (Group Policy) यह नियंत्रित करती है कि DoH की अनुमति है, आवश्यकता है, या यह प्रतिबंधित है। Windows केवल उन कॉन्फ़िगर किए गए DNS सर्वर्स पर DoH सक्षम करता है जो इसका समर्थन करने के लिए जाने जाते हैं। यकीनन यह सबसे साफ़ और स्पष्ट मॉडल है: सिक्योरिटी टीम पॉलिसी चुनती है, और OS उसे लागू करता है।

पैटर्न स्पष्ट है: किसी एक ऐप (ब्राउज़र) में मौजूद DoH को नेटवर्क के लिए कंट्रोल करना मुश्किल होता है; जबकि OS-लेवल रिज़ॉल्वर में मौजूद DoH को सामान्य MDM चैनल्स के ज़रिए कंट्रोल किया जा सकता है। IETF और OS वेंडर्स काफी हद तक इस बात पर सहमत हैं कि पॉलिसी लागू करने का काम OS लेयर का है।

2026 में एक एंटरप्राइज़ के लिए यथार्थवादी विकल्प

ऊपर दिए गए टूल्स को देखते हुए, काम करने योग्य तीन रणनीतियाँ हैं, और एक चौथी रणनीति है जो काम नहीं करेगी।

रणनीति A: पूरी तरह से इंटरनल, DoH ब्लॉक्ड

ऐसी पॉलिसी लागू करें जो हर ब्राउज़र में DoH को डिसेबल कर दे, ज्ञात पब्लिक DoH एंडपॉइंट्स के लिए पोर्ट 443 को ब्लॉक कर दे, और सभी DNS को इंटरनल रिज़ॉल्वर के माध्यम से जाने के लिए बाध्य करे। इंटरनल रिज़ॉल्वर स्वयं अपस्ट्रीम पब्लिक रिज़ॉल्वर्स के साथ DoH पर बात कर सकता है, लेकिन नेटवर्क के अंदर सब कुछ उसी (इंटरनल रिज़ॉल्वर) से होकर गुज़रता है।

यह सबसे ज़्यादा नियंत्रणात्मक (prescriptive) विकल्प है। यह स्प्लिट-होराइज़न को पूरी तरह से सुरक्षित रखता है और सिक्योरिटी टूल्स को पूर्ण विज़िबिलिटी (visibility) देता है। इसकी कीमत यह है कि आपको नए DoH एंडपॉइंट्स की ब्लॉकलिस्ट बनाए रखनी होगी, और यूज़र द्वारा इंस्टॉल किया गया कोई भी ऐप जो अपना ख़ुद का DoH करता है (जैसे कुछ चैट क्लाइंट, कुछ VPN) ख़राब व्यवहार कर सकता है।

रणनीति B: इंटरनल DoH

एक इंटरनल DoH सर्वर (Cloudflared, AdGuard, या DoH-सक्षम Windows DNS सर्वर) स्थापित करें, इसका उपयोग करने के लिए एंडपॉइंट्स को कॉन्फ़िगर करें, और इंटरनल DoH सर्वर पर स्प्लिट-होराइज़न चलाएं। इससे एंडपॉइंट्स को एन्क्रिप्टेड DNS मिल जाता है और नेटवर्क की विज़िबिलिटी भी बनी रहती है।

यह सबसे बेहतर विकल्प है और ज़्यादातर बड़े एंटरप्राइज़ इसी दिशा में आगे बढ़ रहे हैं। यह प्राइवेसी के लाभ (LAN पर क्वेरीज़ एन्क्रिप्टेड होती हैं) को सुरक्षित रखता है और साथ ही सिक्योरिटी का लाभ (इंटरनल रिज़ॉल्वर अभी भी हर क्वेरी को देखता है और फ़िल्टर कर सकता है) भी बनाए रखता है। Microsoft, Google और Apple सभी इस परिदृश्य के लिए OS-लेवल कॉन्फ़िगरेशन का समर्थन करते हैं।

रणनीति C: कैनरी डोमेन / नेटवर्क सिग्नल

Mozilla कैनरी डोमेन पब्लिश करें। संबंधित Chrome और Edge पॉलिसियों को पुश करें। ब्राउज़र्स पर भरोसा करें कि वे यह पता लगा लेंगे कि वे एक मैनेज्ड नेटवर्क पर हैं और सिस्टम रिज़ॉल्वर पर निर्भर हो जाएंगे। यह सबसे कम मेहनत वाला विकल्प (lightest-touch option) है और कई छोटे व मध्यम आकार के संगठनों के लिए पर्याप्त है।

रणनीति D (काम नहीं करती): "हम बस DoH को अनदेखा कर देंगे"

यह मान लेना कि यह टकराव मौजूद ही नहीं है, डिफ़ॉल्ट सेटिंग्स को वैसे ही छोड़ देना, और यह सोचना कि सभी DNS अभी भी कॉर्पोरेट रिज़ॉल्वर के माध्यम से ही प्रवाहित हो रहे हैं। यह सबसे आम स्थिति है और इससे ऐसे फेलियर पैदा होते हैं जिनका अनुमान लगाया जा सकता है: जैसे डेवलपर्स का यह रिपोर्ट करना कि केवल-आंतरिक (internal-only) URL Edge में तो काम करते हैं लेकिन Firefox में नहीं, सिक्योरिटी टीमों को DNS लॉग्स में कमी दिखना, रुक-रुक कर आने वाले VPN-DNS बग्स जिन्हें डायग्नोस करने में घंटों लग जाते हैं। यह समस्या अपने आप ख़त्म नहीं होती। इसके मूल कारण का पता लगाना बस और अधिक कठिन हो जाता है।

DoH केवल प्राइवेसी को ही प्रभावित नहीं करता

DoH का एक और सूक्ष्म प्रभाव रिज़ॉल्वर का केंद्रीकरण (resolver centralization) है। जब किसी ब्राउज़र या OS को पब्लिक DoH रिज़ॉल्वर का उपयोग करने के लिए कॉन्फ़िगर किया जाता है, तो उस यूज़र की ज़्यादातर DNS स्ट्रीम किसी एक ही रिज़ॉल्वर ऑपरेटर के पास जा सकती है। Chrome का ऑटोमैटिक मोड स्पष्ट रूप से जहां तक संभव हो यूज़र के मौजूदा DNS प्रोवाइडर को संरक्षित रखने के लिए डिज़ाइन किया गया है, और Firefox का डिफ़ॉल्ट रोलआउट स्थान और ह्यूरिस्टिक पर निर्भर करता है, इसलिए यह सचमुच हर डिप्लॉयमेंट में "प्रत्येक क्वेरी" पर लागू नहीं होता है। लेकिन आर्किटेक्चर से जुड़ा यह समझौता (trade-off) बना रहता है: एन्क्रिप्टेड DNS, भरोसे (trust) को लोकल नेटवर्क या ISP से हटाकर कुछ चुनिंदा रिज़ॉल्वर ऑपरेटर्स के एक छोटे समूह में स्थानांतरित कर सकता है।

यह ट्रेड-ऑफ़ स्वीकार्य है या नहीं, यह थ्रेट मॉडल (threat model) पर निर्भर करता है। एक असुरक्षित कॉफ़ी-शॉप नेटवर्क पर मौजूद यूज़र के लिए, कॉफ़ी शॉप पर भरोसा करने के बजाय Cloudflare के साथ अपना भरोसा केंद्रित करना निश्चित रूप से एक बेहतर विकल्प है। लेकिन किसी ऐसे एंटरप्राइज़ के लिए, जिसका पहले से ही अपने ISP के साथ कोई अनुबंध (contract) है, यह पीछे जाने (regression) जैसा हो सकता है। शुरुआती DoH रोलआउट्स के समय से ही EFF इस ट्रेड-ऑफ़ के बारे में लिखता आ रहा है।

इसका सबसे साफ़ और सही जवाब ऊपर दी गई रणनीति B ही है: अपना ख़ुद का DoH रिज़ॉल्वर चलाएँ, ताकि एन्क्रिप्टेड DNS के लिए पूरी क्वेरी स्ट्रीम के साथ किसी थर्ड-पार्टी पर भरोसा करने की आवश्यकता न पड़े।

डोमेन मालिकों के लिए इसका क्या मतलब है

यदि आप कोई ऐसा डोमेन चलाते हैं जिसका उपयोग एंटरप्राइज़ द्वारा किया जाता है—जैसे कोई SaaS ऐप, कोई डेवलपर टूल, या कोई API—तो प्रासंगिक तथ्य इस प्रकार हैं:

आपके कुछ यूज़र्स एक पब्लिक DoH एंडपॉइंट के ज़रिए आपको रिज़ॉल्व करेंगे, ख़ासकर अनमैनेज्ड डिवाइस या विशेष रूप से कॉन्फ़िगर किए गए ब्राउज़र्स पर। CNAME चेन्स, सबडोमेन डेलीगेशन्स, और वैयक्तिकरण (personalization) के लिए आप जो भी चतुर DNS ट्रिक्स अपनाते हैं, उन्हें किसी कस्टमर के इंटरनल रिज़ॉल्वर से रिज़ॉल्व होने पर और किसी यादृच्छिक (arbitrary) पब्लिक रिज़ॉल्वर से रिज़ॉल्व होने पर समान रूप से काम करना चाहिए।
DNS-आधारित सेंसरशिप से बचना DoH का एक वास्तविक उपयोग (use case) है। यदि आपका डोमेन किसी सरकार के DNS फ़िल्टर द्वारा ब्लॉक किया गया है (जैसा कि कई एन्क्रिप्टेड-मैसेजिंग और VPN डोमेन के साथ हुआ है), तो यूज़र एक पब्लिक रिज़ॉल्वर से DoH के ज़रिए आप तक पहुँचेंगे। कार्यप्रणाली (mechanics) वही रहती है; बस राजनीतिक दांव अलग होते हैं।
इंटरनल स्प्लिट-होराइज़न को कभी भी किसी पब्लिक-फ़ेसिंग नाम को किसी ऐसी चीज़ में रिज़ॉल्व नहीं करना चाहिए जो केवल आंतरिक रूप से अर्थपूर्ण हो, क्योंकि यदि कोई यूज़र गलती से DoH पर क्वेरी करता है तो यह काम करना बंद कर देगा। इसके फेल होने का क्लासिक उदाहरण यह है कि केवल-आंतरिक (internal-only) app.example.com कोई ऐसा प्राइवेट IP वापस करता है जिस तक कोई भी DoH यूज़र नहीं पहुँच सकता—फिर किसी होटल में बैठे एक दूरस्थ कर्मचारी (remote employee) को वही होस्टनेम अनरीचेबल (unreachable) मिलता है और वह एक बग रिपोर्ट फ़ाइल करता है। इसके बजाय, एक स्पष्ट रूप से अलग केवल-आंतरिक ज़ोन (internal-only zone) (app.example.internal) का उपयोग करें।

इसमें Namefi की क्या भूमिका है

Namefi DNS को एक पब्लिक-फ़ेसिंग कंट्रोल प्लेन (control plane) के रूप में देखता है—एक ऐसा स्थान जहाँ ग्लोबल नेमिंग, लोकल पॉलिसी से मिलती है। हमारे DNS वर्कफ़्लो यह मानकर चलते हैं कि क्वेरीज़ किसी भी रिज़ॉल्वर से आ सकती हैं, जिसमें ऐसे DoH एंडपॉइंट्स भी शामिल हैं जिन्हें हम गिन नहीं सकते, और हमारे द्वारा पब्लिश किए जाने वाले नाम इन सब के बावजूद लगातार सही काम करते हैं। इंटरनल रूप से स्प्लिट-होराइज़न चलाने वाले ग्राहकों के लिए, हम पब्लिक साइड में मौजूद रहते हैं: example.com के लिए आधिकारिक उत्तर (authoritative answer) वही है जो हम प्रदान करते हैं, और इंटरनल यूज़र्स के लिए इंटरनल रिज़ॉल्वर जो भी ओवरराइड करता है, वह उनके और उनकी एंडपॉइंट पॉलिसी के बीच का मामला है।

गहरी बात यह है कि: एन्क्रिप्टेड DNS अब हमेशा रहने वाला है, और एंटरप्राइज़ विज़िबिलिटी भी। इन दोनों में तालमेल बिठाने का तरीका मानकों (standards) से लड़ना नहीं है, बल्कि पॉलिसी लागू करने के पॉइंट को नेटवर्क से हटाकर ऑपरेटिंग सिस्टम पर ले जाना है। मानक निकाय (standards bodies), Microsoft, Apple, Google और Mozilla सभी इसी निष्कर्ष पर पहुँचे हैं। अब जो काम बचा है वह मुख्य रूप से ऑपरेशनल (संचालन संबंधी) है।