डीएनएस अवलोकन

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

एक पेज HTTPS द्वारा पूरी तरह से सुरक्षित हो सकता है और फिर भी आपके द्वारा देखी जाने वाली साइटों की सूची डीएनएस के माध्यम से लीक हो सकती है। डीएनएस गोपनीयता पर आईईटीएफ (IETF) का विश्लेषण, RFC 9076, इसे एक उदाहरण के साथ रखता है: ‘अल्कोहलिक्स एनोनिमस’ की वेबसाइट सार्वजनिक है, लेकिन यह तथ्य कि आपने इसे देखा, सार्वजनिक नहीं होना चाहिए।

इसे पढ़ने के बाद आपको पता चल जाएगा कि आपकी लुकअप खोजों को कौन देख सकता है, एन्क्रिप्टेड डीएनएस क्या ठीक करता है और क्या उजागर छोड़ देता है, DNSSEC कहाँ फिट बैठता है, और कौन सी सेटिंग्स आपके दस मिनट के समय के लायक हैं। हम किसी विशिष्ट डीएनएस प्रदाता को चुनने, डीएनएस-आधारित विज्ञापन अवरोधन (ad blocking), या अपना खुद का रिज़ॉल्वर चलाने को कवर नहीं करते हैं। इनमें से प्रत्येक को अपने स्वयं के पृष्ठ की आवश्यकता है।

सरल शब्दों में डीएनएस क्या है

कंप्यूटर आईपी पते (IP addresses) नामक संख्याओं द्वारा एक-दूसरे को ढूंढते हैं। लोग example.org जैसे नामों का उपयोग करते हैं। डीएनएस वह लुकअप सेवा है जो एक को दूसरे में बदलती है। आपके डिवाइस पर मौजूद सॉफ़्टवेयर (जिसे स्टब रिज़ॉल्वर कहा जाता है) प्रत्येक प्रश्न को एक रिकर्सिव रिज़ॉल्वर (recursive resolver) को सौंपता है, जो एक ऐसा सर्वर है जो उत्तर खोजने का काम करता है (RFC 9076)।

यहाँ एक ठोस मामला है। आप किसी हवाई अड्डे पर वाई-फ़ाई से जुड़ते हैं और अपने क्लिनिक का पेशेंट पोर्टल खोलते हैं। आपके फ़ोन ने कोई रिज़ॉल्वर नहीं चुना। जब आप कनेक्ट हुए तो नेटवर्क ने उसे बताया कि किसका उपयोग करना है, जो कि सामान्य व्यवस्था है, और RFC 9076 नोट करता है कि अधिकांश लोग इसे कभी नहीं बदलते हैं। इसलिए हवाई अड्डे का रिज़ॉल्वर, या उसके इंटरनेट प्रदाता का रिज़ॉल्वर, अब यह रिकॉर्ड रखता है कि आपके फ़ोन ने सुबह 9:14 बजे क्लिनिक का पता माँगा था।

लुकअप कैसे काम करता है

www.example.com के लिए एक लुकअप लें जब रास्ते में कहीं भी कुछ भी सहेजा नहीं गया हो:

1. आपका स्टब रिज़ॉल्वर रिकर्सिव रिज़ॉल्वर से पूछता है।
2. रिकर्सिव रिज़ॉल्वर एक रूट नेम सर्वर (root name server) से पूछता है। रूट उत्तर नहीं जानता है, लेकिन यह उन सर्वरों की ओर इशारा करता है जो .com के लिए जिम्मेदार हैं।
3. रिज़ॉल्वर एक .com सर्वर से पूछता है, जो उन सर्वरों की ओर इशारा करता है जो example.com को संभालते हैं।
4. रिज़ॉल्वर उन सर्वरों से पूछता है। उन्हें आधिकारिक नेम सर्वर (authoritative name servers) कहा जाता है क्योंकि वे वास्तविक रिकॉर्ड रखते हैं, और वे आईपी पता लौटाते हैं।
5. रिकर्सिव रिज़ॉल्वर उत्तर आपके डिवाइस को सौंप देता है और सीमित समय के लिए एक प्रति रखता है।

वह प्रति (cache) ही कारण है कि अधिकांश लुकअप चरण 2 से 4 को छोड़ देते हैं। यही कारण भी है कि अलग-अलग सर्वर अलग-अलग मात्रा में जानकारी देखते हैं। एक स्टब रिज़ॉल्वर आमतौर पर कैश नहीं करता है, इसलिए रिकर्सिव रिज़ॉल्वर आपकी लगभग सभी लुकअप खोजों को देखता है, जबकि आधिकारिक सर्वर केवल उन्हीं को देखते हैं जिनका उत्तर रिज़ॉल्वर मेमोरी से नहीं दे सका (RFC 9076)। जब तक रिज़ॉल्वर QNAME मिनिमाइजेशन नामक तकनीक का उपयोग नहीं करता है, श्रृंखला में ऊपर प्रत्येक सर्वर को आपका पूरा मूल प्रश्न प्राप्त होता है, केवल वह हिस्सा नहीं जिसकी उसे आवश्यकता होती है।

एक पेज का अर्थ कई लुकअप भी होता है। एम्बेडेड छवियों, स्क्रिप्टों और विज्ञापनों के कारण एक अकेला वेब पेज दर्जनों डोमेन नामों के लिए लुकअप ट्रिगर कर सकता है, और ब्राउज़र कभी-कभी आपके क्लिक करने की स्थिति के लिए समय से पहले ही नामों को खोज लेते हैं (RFC 9076)। आपका रिज़ॉल्वर जो सूची बनाता है वह उन साइटों की सूची से अधिक लंबी और अधिक खुलासा करने वाली होती है जिन पर आप जाने का इरादा रखते थे।

आपकी लुकअप खोजों को कौन देख सकता है

यह इस बात पर निर्भर करता है कि आपका रिज़ॉल्वर कहाँ स्थित है और क्या ट्रैफ़िक एन्क्रिप्टेड है।

तालिका की पंक्तियाँ RFC 9076 से आती हैं, जो “उत्तरों को बदलने” वाले हिस्से को भी कवर करती हैं: नेटवर्क को नियंत्रित करने वाला एक हमलावर किसी भी अन-एन्क्रिप्टेड लुकअप के लिए अपने उत्तरों को प्रतिस्थापित कर सकता है।

आपके रिज़ॉल्वर का ऑपरेटर डेटा के साथ क्या करता है यह नीति का सवाल है, और नीतियां अलग-अलग होती हैं। RFC 9076 कहता है कि नेटवर्क-प्रदत्त रिज़ॉल्वर के लिए गोपनीयता नीतियां उपलब्ध हो भी सकती हैं और नहीं भी, जबकि गूगल पब्लिक डीएनएस (Google Public DNS), क्लाउडफ़ेयर (Cloudflare) और Quad9 जैसी बड़ी सार्वजनिक सेवाएं अपनी नीतियां प्रकाशित करती हैं। कुछ रिज़ॉल्वर जानबूझकर कुछ डोमेन को ब्लॉक भी करते हैं, जो आमतौर पर ज्ञात मैलवेयर साइटें होती हैं। जब यह वही होता है जो आप चाहते हैं तो यह उपयोगी होता है और जब ऐसा नहीं होता तो भ्रमित करने वाला होता है।

एन्क्रिप्टेड डीएनएस क्या ठीक करता है, और क्या उजागर छोड़ देता है

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

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

सीमाएँ उतनी ही मायने रखती हैं जितना कि लाभ:

• रिज़ॉल्वर अभी भी सब कुछ देखता है। RFC 9076 स्पष्ट है कि एन्क्रिप्टेड ट्रांसपोर्ट यह कम नहीं करते हैं कि रिज़ॉल्वर क्या सीखता है, और यहाँ तक कि इसे सह-संबंधित (correlate) करने के लिए और अधिक दे सकते हैं। आपने किसी देखने वाले को हटाया नहीं है। आपने चुना है कि किस पर भरोसा करना है।
• ट्रैफ़िक विश्लेषण अभी भी एक सीमा तक काम करता है। एन्क्रिप्टेड प्रश्नों के आकार और समय का मिलान रिज़ॉल्वर द्वारा अपस्ट्रीम भेजे जाने वाले प्रश्नों से किया जा सकता है। पैडिंग (Padding) इसे कम करती है, लेकिन RFC 7858 कहता है कि केवल साधारण पैडिंग ही पर्याप्त नहीं हो सकती है।
• कमजोर कॉन्फ़िगरेशन को डाउनग्रेड किया जा सकता है। यदि आपका डिवाइस नेटवर्क से एक एन्क्रिप्टेड रिज़ॉल्वर के बारे में सीखता है और इसे सत्यापित नहीं करता है, तो उस नेटवर्क पर एक हमलावर हस्तक्षेप कर सकता है (RFC 7858)। एंड्रॉइड का “प्राइवेट डीएनएस प्रदाता होस्टनेम” मोड सख्त प्रकार का है: यह आपके द्वारा नामित सर्वर को एक सुरक्षित चैनल पर प्रश्न भेजता है, या यदि यह उस सर्वर तक नहीं पहुँच सकता है तो नेटवर्क को इंटरनेट एक्सेस न होने के रूप में चिह्नित करता है (गूगल सिक्योरिटी ब्लॉग, 2018)।
• एक छोटा रिज़ॉल्वर आपको ट्रैक करना आसान बना सकता है। RFC 9076 देखता है कि कम उपयोगकर्ताओं वाला एक रिज़ॉल्वर, एन्क्रिप्शन के बाद भी, किसी को नेटवर्क से नेटवर्क तक आपका पीछा करने में मदद कर सकता है।
• यह फ़िल्टर बंद कर सकता है। मोज़िला का दस्तावेज़ीकरण कहता है कि DoH स्थानीय रिज़ॉल्वर को और उनके साथ किसी भी मैलवेयर ब्लॉकिंग या अभिभावकीय नियंत्रण (parental controls) को बायपास करता है, यही वजह है कि फ़ायरफ़ॉक्स इनकी जांच करता है और मिलने पर पीछे हट जाता है।
• नेटवर्क इसे ब्लॉक कर सकते हैं, और डिवाइस वापस पुरानी स्थिति में आ सकते हैं (fall back)। RFC 7858 चेतावनी देता है कि पोर्ट 853 को कुछ फ़ायरवॉल द्वारा ब्लॉक किया जा सकता है। फ़ायरफ़ॉक्स का डिफ़ॉल्ट रोलआउट एक फ़ॉलबैक मोड का उपयोग करता है, इसलिए यदि DoH लुकअप विफल रहता है तो यह चुपचाप सिस्टम के साधारण डीएनएस का उपयोग करता है।

साइट का नाम दूसरी बार लीक होता है

लुकअप को एन्क्रिप्ट करने से काम पूरा नहीं होता। जब आपका ब्राउज़र एक HTTPS कनेक्शन खोलता है, तो उसके पहले संदेश में उस साइट का नाम शामिल होता है जो वह चाहता है, वो भी प्लेन टेक्स्ट में। उस फ़ील्ड को सर्वर नेम इंडिकेशन (Server Name Indication) या SNI कहा जाता है, और कनेक्शन देखने वाला कोई भी व्यक्ति इसे पढ़ सकता है (क्लाउडफ़ेयर, 2023)।

एन्क्रिप्टेड क्लाइंट हेलो (Encrypted Client Hello) या ECH, उस अंतर को बंद कर देता है। साइट का नाम संदेश के एक एन्क्रिप्टेड हिस्से के अंदर जाता है, और दृश्यमान हिस्सा इसके बजाय एक साझा नाम ले जाता है। क्लाउडफ़ेयर पर, हर ECH-सक्षम साइट एक ही बाहरी नाम, cloudflare-ech.com, दिखाती है। मोज़िला का एफएक्यू कहता है कि फ़ायरफ़ॉक्स ने संस्करण 119 के बाद से डिफ़ॉल्ट रूप से ECH को सक्षम किया है, और गोपनीयता लाभ को सबसे मजबूत बताता है जब कई साइटें एक सर्वर साझा करती हैं। ECH केवल तभी काम करता है जब साइट इसका समर्थन करती है, और मोज़िला का कहना है कि कई साइटें अभी ऐसा नहीं करती हैं।

ECH एक तरह से डीएनएस से जुड़ा हुआ है और एक अंतर छोड़ता है। फ़ायरफ़ॉक्स में, ECH को अपनी एन्क्रिप्शन कुंजियाँ एक डीएनएस रिकॉर्ड से मिलती हैं, और मोज़िला का कहना है कि DoH के साथ इसका सबसे अधिक गोपनीयता लाभ है। अंतर सर्वर का आईपी पता है, जिसे आपका प्रदाता अभी भी देखता है। यदि किसी साइट का अपना एक सर्वर है, तो अकेला वह पता ही इसे उजागर कर सकता है।

DNSSEC क्या जोड़ता है

DNSSEC (DNS Security Extensions का संक्षिप्त रूप) किसी डोमेन के मालिक को उसके डीएनएस रिकॉर्ड पर हस्ताक्षर करने देता है। हस्ताक्षरों की जांच करने वाला रिज़ॉल्वर यह बता सकता है कि आपके पास आते समय उत्तर जाली था या बदला गया था। RFC 7858 इसे प्रतिक्रिया अखंडता (response integrity) के रूप में वर्णित करता है। हस्ताक्षरों की श्रृंखला एक रूट कुंजी से शुरू होती है जिसे मान्य करने वाले रिज़ॉल्वर अपने ट्रस्ट एंकर के रूप में रखते हैं।

यह किसी भी चीज़ को एन्क्रिप्ट नहीं करता है। RFC 9076 कहता है कि DNSSEC स्पष्ट रूप से गोपनीयता (confidentiality) को अपने लक्ष्यों से बाहर रखता है। यह केवल उन डोमेन की सुरक्षा करता है जिनके मालिकों ने उन पर हस्ताक्षर किए हैं और वे रिज़ॉल्वर जो जांच करते हैं, और यह इस बारे में कुछ नहीं कहता है कि अंत में साइट ईमानदार है या नहीं। एक मिलते-जुलते डोमेन पर एक घोटाला साइट पूरी तरह से हस्ताक्षरित हो सकती है। DoH के साथ, आपका डिवाइस या तो स्वयं DNSSEC को मान्य करता है या DoH सर्वर की रिपोर्ट पर भरोसा करता है (RFC 8484)।

अक्टूबर 2026 तक एक जीवंत उदाहरण है। आईकैन (ICANN) का कहना है कि एक नई रूट कुंजी, KSK-2024, ने 11 अक्टूबर 2026 को 14:00 UTC पर डीएनएस रूट ज़ोन पर हस्ताक्षर करना शुरू कर दिया, और उसने व्यापक व्यवधान के कोई संकेत नहीं देखे थे। इसके निर्देश उन लोगों को संबोधित हैं जो मान्य करने वाले रिज़ॉल्वर चलाते हैं, जिन्हें यह पुष्टि करने की आवश्यकता है कि नई कुंजी उनके कॉन्फ़िगरेशन में है। जब तक आप अपना स्वयं का रिज़ॉल्वर नहीं चलाते हैं, आपके करने के लिए कुछ नहीं है।

आम मिथक

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

“DNSSEC और एन्क्रिप्टेड डीएनएस एक ही चीज़ हैं।” वे अलग-अलग समस्याओं को हल करते हैं। RFC 7858 और RFC 8484 दोनों कहते हैं कि दोनों स्वतंत्र और संगत हैं, और एक का उपयोग करने से दूसरा प्रतिस्थापित नहीं होता है।

“DoH निजी वाला है और DoT कमजोर वाला है।” विनिर्देश किसी विजेता का समर्थन नहीं करते हैं। RFC 9076 नोट करता है कि DoH अधिक HTTP सुविधाएँ रखता है जो पहचानकर्ता के रूप में कार्य कर सकती हैं, और कहता है कि गोपनीयता-केंद्रित उपयोगकर्ता उन कार्यान्वयनों को पसंद कर सकते हैं जो इस बारे में स्पष्ट हैं कि वे क्या भेजते हैं। RFC 8484 कहता है कि DoH के बारे में HTTPS से परे अतिरिक्त चिंताएं जोड़ने के लिए नहीं जाना जाता है। व्यवहार में अंतर रिज़ॉल्वर के चयन के आगे छोटा है।

क्या करें

क्या इसमें से कुछ भी आपके समय के लायक है यह इस बात पर निर्भर करता है कि आप किसके बारे में चिंतित हैं: एक शत्रुतापूर्ण वाई-फ़ाई ऑपरेटर, आपका इंटरनेट प्रदाता, या एक ऐसा नेटवर्क जो साइटों को ब्लॉक करता है। यदि आपने अभी तक इसका नक्शा नहीं बनाया है, तो थ्रेट मॉडलिंग (threat modeling) से शुरुआत करें। नीचे दिए गए कदम सबसे कम प्रयास में सबसे अधिक मदद के क्रम में व्यवस्थित हैं। यह पृष्ठ सामान्य जानकारी है, विशिष्ट स्थिति के लिए पेशेवर सुरक्षा सलाह नहीं।

1. केवल एक ऐप के लिए नहीं, बल्कि पूरे डिवाइस के लिए एन्क्रिप्टेड डीएनएस चालू करें। सार्वजनिक वाई-फ़ाई से जुड़ने वाले फ़ोनों को सबसे ज़्यादा फ़ायदा होता है। एंड्रॉइड पर, प्राइवेट डीएनएस (Private DNS) देखें, जो आमतौर पर सेटिंग्स के तहत, फिर नेटवर्क और इंटरनेट में मिलता है, हालांकि निर्माता इसे बदलते रहते हैं। “प्राइवेट डीएनएस प्रदाता होस्टनेम” चुनें और अपने प्रदाता का होस्टनेम दर्ज करें। एप्पल का iOS और macOS सिस्टम-व्यापी DoT या DoH का समर्थन करते हैं, लेकिन अक्टूबर 2026 तक हमने केवल यह पुष्टि की है कि एक ऐप इसे सेट कर सकता है और आपको इसे स्वीकृत करना होगा (एप्पल डेवलपर)। नुकसान: कुछ होटल और हवाई अड्डे के लॉगिन पेज नेटवर्क के अपने डीएनएस पर निर्भर करते हैं, और एंड्रॉइड “इंटरनेट एक्सेस नहीं” दिखाएगा यदि यह आपके नामित सर्वर तक नहीं पहुँच सकता है। उस साइन-इन के लिए इसे बंद करें, फिर वापस चालू करें।
2. उद्देश्यपूर्वक रिज़ॉल्वर चुनें। इसकी गोपनीयता नीति पढ़ें कि यह क्या लॉग करता है, कितने समय के लिए, और किसे मिलता है। एक नीति एक वादा है, तकनीकी गारंटी नहीं, हालांकि कुछ सेवाएं अपने समझौतों का समर्थन अनुबंधों से करती हैं, जैसे मोज़िला अपने DoH भागीदारों के साथ करता है। यह पृष्ठ प्रदाताओं को रैंक नहीं करता है।
3. अपने ब्राउज़र को अद्यतन (updated) रखें ताकि ECH काम कर सके। फ़ायरफ़ॉक्स में कॉन्फ़िगर करने के लिए कुछ नहीं है। मोज़िला का एफएक्यू क्लाउडफ़ेयर के ब्राउज़र चेक की ओर इशारा करता है यह देखने के लिए कि क्या यह आपके लिए काम कर रहा है या नहीं।
4. यदि आप अभिभावकीय नियंत्रण (parental controls) या फ़िल्टरिंग रिज़ॉल्वर का उपयोग करते हैं, तो उस रिज़ॉल्वर को अपना एन्क्रिप्टेड रिज़ॉल्वर बनाएं। ब्राउज़र DoH स्थानीय फ़िल्टरिंग को बायपास कर सकता है, और मोज़िला का कहना है कि डीएनएस-आधारित विज्ञापन अवरोधकों को अपस्ट्रीम में एक एन्क्रिप्टेड कनेक्शन का उपयोग करना चाहिए, अन्यथा देखी गई साइटें अप्रत्यक्ष रूप से लीक हो जाती हैं।
5. काम या स्कूल के डिवाइस पर, डीएनएस सेटिंग्स को अकेला छोड़ दें। प्रबंधित नेटवर्क नीतिगत कारणों से DoH को बंद कर सकते हैं, और फ़ायरफ़ॉक्स प्रबंधित उपकरणों पर पीछे हट जाता है। आपके नियोक्ता का रिज़ॉल्वर दोनों तरह से आपकी लुकअप खोजों को देखता है।

अक्टूबर 2026 तक, मोज़िला का कहना है कि संयुक्त राज्य अमेरिका और कनाडा में फ़ायरफ़ॉक्स डेस्कटॉप उपयोगकर्ताओं को डिफ़ॉल्ट रूप से DoH मिलता है, रूस और यूक्रेन में रोलआउट 2022 में शुरू हुआ था, और अधिक देशों की योजना है। डिफ़ॉल्ट रिज़ॉल्वर मोज़िला का एक विश्वसनीय भागीदार है। इसकी सेटिंग्स आपको फ़ायरफ़ॉक्स की सेटिंग्स के ‘DNS over HTTPS’ अनुभाग में ऑप्ट आउट करने या एक अलग प्रदाता चुनने देती हैं।

स्रोत (Sources)

• DNS Privacy Considerations (RFC 9076), IETF, जुलाई 2021
• Specification for DNS over Transport Layer Security (RFC 7858), IETF, मई 2016
• DNS Queries over HTTPS (RFC 8484), IETF, अक्टूबर 2018
• DNS over Dedicated QUIC Connections (RFC 9250), IETF, मई 2022
• Root Zone KSK Rollover, ICANN, अक्टूबर 2026 तक स्थिति
• Firefox DNS over HTTPS, मोज़िला सपोर्ट, 2026
• Encrypted Client Hello (ECH) frequently asked questions, मोज़िला सपोर्ट, अगस्त 2024 को अद्यतन
• Encrypted Client Hello: the last puzzle piece to privacy, क्लाउडफ़ेयर, 2023
• DNS over TLS support in Android P Developer Preview, गूगल सिक्योरिटी ब्लॉग, 2018
• DNS settings, एप्पल डेवलपर दस्तावेज़ीकरण, 2026

संबंधित पृष्ठ (Related pages)

• थ्रेट मॉडलिंग (Threat modeling)
• डिजिटल गोपनीयता और सुरक्षा (Digital privacy and security)