मान लीजिए किसी संगठन ने अपनी वेबसाइट को ठीक से सुरक्षित कर रखा है। एप्लिकेशन पैच किया गया है, एक्सेस के लिए मल्टीफ़ैक्टर ऑथेंटिकेशन ज़रूरी है, और ट्रैफ़िक HTTPS से एन्क्रिप्टेड है।
कोई हमलावर संगठन के डोमेन को मैनेज करने वाले अकाउंट से समझौता कर लेता है और एक DNS रिकॉर्ड बदल देता है। सही वेबसाइट पता डालने वाले यूज़र अब हमलावर के नियंत्रण वाले इंफ़्रास्ट्रक्चर पर भेज दिए जाते हैं।
एप्लिकेशन के साथ सेंधमारी नहीं हुई। यूज़र को वहाँ तक ले जाने वाला रास्ता बदल दिया गया।
यही वजह है कि DNS हमलावरों के लिए क़ीमती बना रहता है। यह ज़्यादातर नेटवर्क कनेक्शन में शुरुआत में ही काम करता है, और इस पर निर्भर रहने वाले सिस्टम इस पर भरोसा करते हैं। कोई सफल हमला ट्रैफ़िक को मोड़ सकता है, सेवाओं में रुकावट डाल सकता है, क्रेडेंशियल चोरी में मदद कर सकता है, या मैलवेयर के साथ संचार छुपा सकता है।
DNS सुरक्षा कोई एक सर्वर-हार्डनिंग समस्या नहीं है। DNS सिस्टम के अलग-अलग हिस्से अलग-अलग काम करते हैं, और हर एक अपना अलग हमला-सतह (attack surface) बनाता है।
तीन DNS भूमिकाएँ जिन्हें गड्डमड्ड नहीं करना चाहिए
| DNS भूमिका | यह क्या करती है | हमलावर को क्या मिलता है |
|---|---|---|
| ऑथॉरिटेटिव DNS | किसी डोमेन के आधिकारिक रिकॉर्ड प्रकाशित करता है | उस डोमेन का इस्तेमाल करने वाली सेवाओं को मोड़ने या बाधित करने की क्षमता |
| रिकर्सिव रिज़ॉल्वर | यूज़र्स के लिए DNS जवाब ढूँढता है और उन्हें कैश करता है | कई क्लाइंट कहाँ कनेक्ट होते हैं, इसे प्रभावित या निरीक्षण करने की क्षमता |
| DNS प्रशासन | डोमेन, नेम सर्वर, रिकॉर्ड, और साइनिंग कुंजियों को नियंत्रित करता है | ख़ुद DNS कॉन्फ़िगरेशन पर नियंत्रण |
कोई संगठन इनमें से कुछ काम अंदरूनी तौर पर चला सकता है, और बाक़ी रजिस्ट्रार, क्लाउड प्रोवाइडर, या मैनेज्ड DNS सेवाओं से ले सकता है। हर भूमिका को कौन संभालता है, यह जानना उसे सुरक्षित करने की शुरुआत है।
DNS इतनी बढ़त (leverage) क्यों देता है
यह लगभग हर कनेक्शन का हिस्सा है
यूज़र portal.example.com जैसे नामों से काम करते हैं। एप्लिकेशन को आख़िरकार नेटवर्क पते और दूसरी सेवा-जानकारी चाहिए होती है। DNS वह मैपिंग उपलब्ध कराता है।
अगर DNS उपलब्ध न हो, तो सर्वर सही-सलामत होने पर भी कई एप्लिकेशन अनुपलब्ध दिखने लगते हैं। अगर DNS ग़लत जवाब देता है, तो क्लाइंट ग़लत जगह से जुड़ सकता है। इसी वजह से DNS एक निर्भरता भी है और एक नियंत्रण बिंदु भी।
यह सिर्फ़ वेबसाइटों से ज़्यादा सेवा करता है
DNS रिकॉर्ड ईमेल सिस्टम, आइडेंटिटी सेवाओं, एप्लिकेशन एंडपॉइंट्स, और दूसरे इंफ़्रास्ट्रक्चर को ढूँढने में मदद करते हैं। SPF, DKIM, और DMARC जैसी तकनीकें भी ईमेल ऑथेंटिकेशन के हिस्से के रूप में DNS रिकॉर्ड इस्तेमाल करती हैं।
Windows वातावरण में, DNS Active Directory की सर्विस डिस्कवरी से गहराई से जुड़ा होता है। इसलिए अंदरूनी DNS को नुक़सान, ऑथेंटिकेशन, पॉलिसी लागू होने, और संगठन के संसाधनों तक पहुँच में रुकावट डाल सकता है।
यह एक पुराने भरोसे वाले मॉडल के लिए बनाया गया था
पारंपरिक DNS ने वितरित नेम रिज़ॉल्यूशन और उपलब्धता को प्राथमिकता दी। बुनियादी DNS जवाब यह क्रिप्टोग्राफ़िक रूप से साबित करने के लिए नहीं बनाए गए थे कि जवाब असली मालिक से आया है या बदला नहीं गया है।
सुरक्षा एक्सटेंशन और एन्क्रिप्टेड ट्रांसपोर्ट इस कमज़ोरी के कुछ हिस्सों को दूर करते हैं, लेकिन इनका इस्तेमाल अपने आप नहीं हो जाता, और हर नियंत्रण अलग समस्या हल करता है।
सारे हमले एक जैसे नहीं होते
डोमेन और रिकॉर्ड हाईजैकिंग
अगर कोई हमलावर किसी रजिस्ट्रार, DNS-होस्टिंग, या प्रशासनिक अकाउंट से समझौता कर लेता है, तो वह नेम-सर्वर डेलिगेशन या अलग-अलग रिकॉर्ड बदल सकता है। यह एक कंट्रोल-प्लेन हमला है: हमलावर वैध प्रबंधन क्षमताओं का इस्तेमाल बिना वैध अधिकार के कर रहा है।
इसके नतीजे वेबसाइट रीडायरेक्शन से आगे भी जा सकते हैं। DNS बदलाव ईमेल को मोड़ सकते हैं, डोमेन-वैलिडेशन प्रक्रियाओं में रुकावट डाल सकते हैं, या कुछ हालात में हमलावर को भरोसेमंद सर्टिफ़िकेट पाने में मदद कर सकते हैं।
यहाँ मज़बूत ऑथेंटिकेशन, सीमित प्रशासनिक भूमिकाएँ, जहाँ उपलब्ध हो वहाँ रजिस्ट्री लॉक, बदलाव पर अलर्ट, और DNS प्लेटफ़ॉर्म से अलग रखी गई रिकवरी प्रक्रिया — ये DNS सर्वर सॉफ़्टवेयर को हार्डन करने से ज़्यादा मायने रखते हैं।
डिनायल ऑफ़ सर्विस
हमलावर ऑथॉरिटेटिव सर्वर या रिज़ॉल्वर पर तब तक ट्रैफ़िक भर सकते हैं जब तक वैध अनुरोधों का जवाब न दिया जा सके। इतने सारे एप्लिकेशन DNS पर निर्भर होने की वजह से, एक हमला कई सेवाओं को एक साथ ऑफ़लाइन जैसा दिखा सकता है।
एक ही इमारत या नेटवर्क में मौजूद रिडंडेंट सर्वर पर्याप्त रेज़िलिएंस नहीं देते। संगठनों को अपने जोखिम के हिसाब से प्रोवाइडर, नेटवर्क, और भौगोलिक विविधता चाहिए होती है। मैनेज्ड ऑथॉरिटेटिव प्लेटफ़ॉर्म अक्सर एनीकास्ट का इस्तेमाल करते हैं, जो सेवा को कई जगहों पर फैला देता है, लेकिन ग्राहकों को उस सेवा को नियंत्रित करने वाले अकाउंट और कॉन्फ़िगरेशन की सुरक्षा फिर भी ख़ुद करनी होती है।
कैश पॉइज़निंग
परफ़ॉर्मेंस बेहतर करने के लिए रिकर्सिव रिज़ॉल्वर जवाबों को कैश करते हैं। अगर कोई हमलावर किसी रिज़ॉल्वर से एक जाली जवाब सेव करवा देता है, तो उस कैश पर निर्भर क्लाइंट हमलावर की चुनी हुई जगह पर भेजे जा सकते हैं।
आधुनिक रिज़ॉल्वर में सुरक्षा उपाय होते हैं, और DNSSEC साइन किए गए DNS डेटा को वैलिडेट करने देता है। फिर भी कैश पॉइज़निंग पूरी तरह ख़त्म नहीं हुई है। पार्सिंग, कैशिंग, और वैलिडेशन का व्यवहार जटिल बना रहता है, इसलिए प्रोटोकॉल और इम्प्लीमेंटेशन पर काम जारी है।
रिफ़्लेक्शन और एम्प्लिफ़िकेशन
DNS आम तौर पर UDP इस्तेमाल करता है, जो जवाब भेजने से पहले कनेक्शन स्थापित नहीं करता। कोई हमलावर पीड़ित का सोर्स एड्रेस जाली बनाकर, खुले DNS सर्वरों को क्वेरी भेज सकता है। वे सर्वर फिर पीड़ित को जवाब भेजते हैं।
जब एक छोटी क्वेरी बड़ा जवाब पैदा करती है, तो हमले को एम्प्लिफ़िकेशन मिलता है। रिकर्सिव सेवा को स्वीकृत क्लाइंट तक सीमित रखना, खुले रिज़ॉल्वर से बचना, और सोर्स-एड्रेस वैलिडेशन लागू करना इस दुरुपयोग को घटाने में मदद करता है।
मैलवेयर चैनल के रूप में DNS
मैलवेयर को अक्सर कमांड इंफ़्रास्ट्रक्चर ढूँढना होता है या नेटवर्क के बाहर जानकारी भेजनी होती है। उस संचार को ब्लॉक करना मुश्किल बनाने के लिए हमलावर तेज़ी से बदलते डोमेन, जनरेट किए गए डोमेन नाम, फ़ास्ट-फ़्लक्स इंफ़्रास्ट्रक्चर, या DNS टनलिंग का इस्तेमाल कर सकते हैं।
इसलिए DNS सिर्फ़ सुरक्षा करने की चीज़ नहीं है। यह क़ीमती सुरक्षा टेलीमेट्री भी है। असामान्य क्वेरी मात्रा, लंबे एन्कोडेड-से दिखने वाले नाम, नए रजिस्टर किए गए डोमेन, और बार-बार होने वाली विफलताएँ समझौता किए गए डिवाइस उजागर कर सकती हैं।
DNSSEC और एन्क्रिप्टेड DNS असल में क्या हल करते हैं
DNS सुरक्षा पर चर्चाएँ अक्सर DNSSEC, DNS over HTTPS, और DNS over TLS को आपस में बदले जा सकने वाले सुधार मान लेती हैं। ये अलग-अलग चीज़ों की रक्षा करते हैं।
DNSSEC एक वैलिडेटिंग रिज़ॉल्वर को साइन किए गए DNS डेटा का स्रोत और अखंडता (integrity) जाँचने देता है। यह जाली जवाबों और कैश पॉइज़निंग से बचाव में मदद करता है। यह क्वेरी को एन्क्रिप्ट नहीं करता, कौन-सा डोमेन माँगा गया यह छुपाता नहीं, और हमले के दौरान DNS सेवा को उपलब्ध नहीं रखता।
DNS over HTTPS (DoH) और DNS over TLS (DoT) क्लाइंट और रिज़ॉल्वर के बीच DNS ट्रैफ़िक को एन्क्रिप्ट करते हैं। यह उस रास्ते पर साधारण निगरानी या छेड़छाड़ से क्वेरी की रक्षा करता है। यह साबित नहीं करता कि डोमेन के मालिक ने सही रिकॉर्ड प्रकाशित किया, और न ही यह चुने गए रिज़ॉल्वर को भरोसेमंद बनाता है।
एन्क्रिप्टेड DNS एक ऑपरेशनल ट्रेड-ऑफ़ भी पैदा करता है। अगर डिवाइस चुपचाप बाहरी रिज़ॉल्वर इस्तेमाल करने लगें, तो संगठन अपनी स्वीकृत DNS सेवा पर पॉलिसी लागू करने और निगरानी करने की क्षमता खो सकता है। इसलिए सुरक्षित तैनाती के लिए सिर्फ़ एन्क्रिप्शन चालू करने से ज़्यादा कुछ चाहिए — यह तय करना ज़रूरी है कि कौन-से रिज़ॉल्वर अधिकृत हैं और DNS गतिविधि किस हद तक देखी जा सकेगी।
एक व्यावहारिक बचाव मॉडल
अथॉरिटी की रक्षा करें
- जहाँ समर्थित हो, वहाँ रजिस्ट्रार और DNS-होस्टिंग अकाउंट के लिए फ़िशिंग-प्रतिरोधी मल्टीफ़ैक्टर ऑथेंटिकेशन इस्तेमाल करें।
- रोज़मर्रा के यूज़र अकाउंट को DNS प्रशासन से अलग रखें।
- डेलिगेशन, रिकॉर्ड, और DNSSEC कुंजियाँ कौन बदल सकता है, इसे सीमित करें।
- नेम-सर्वर, ज़ोन, रिकॉर्ड, और अकाउंट में बदलाव पर अलर्ट सेट करें।
- रिकवरी संपर्कों और डोमेन-स्वामित्व के प्रमाण को प्रभावित DNS प्लेटफ़ॉर्म से बाहर रखें।
भूमिकाओं को अलग रखें
ऑथॉरिटेटिव सर्वर को ज़ोन प्रकाशित करने चाहिए। रिकर्सिव रिज़ॉल्वर को क्लाइंट का जवाब देना चाहिए। पब्लिक ऑथॉरिटेटिव सेवा को अप्रतिबंधित रिकर्शन के साथ मिलाना जोखिम बढ़ाता है और पॉलिसी समझना मुश्किल कर देता है।
रिकर्शन को स्वीकृत नेटवर्क या पहचानों तक सीमित रखें। ज़ोन ट्रांसफ़र सिर्फ़ अधिकृत सेकेंडरी सर्वर को ही करने दें। जहाँ व्यावहारिक हो, मैनेजमेंट इंटरफ़ेस को पब्लिक इंटरनेट से दूर रखें।
विफलता के लिए डिज़ाइन करें
जब बिज़नेस पर असर इसे सही ठहराए, तो स्वतंत्र ऑथॉरिटेटिव सर्वर इस्तेमाल करें और सिंगल-प्रोवाइडर या सिंगल-नेटवर्क निर्भरता हटाएँ। संगठन के बाहर से DNS की निगरानी करें ताकि विफलताएँ तब भी पकड़ में आएँ जब अंदरूनी निगरानी उसी DNS सेवा पर निर्भर हो।
ज़ोन डेटा और कॉन्फ़िगरेशन का बैकअप लें, लेकिन रीस्टोरेशन का परीक्षण भी करें। अगर रिकवरी प्रक्रिया उन परतों को कवर नहीं करती, तो बैकअप रजिस्ट्रार समझौते या दुर्भावनापूर्ण डेलिगेशन बदलावों को हल नहीं करता।
DNS को सुरक्षा नियंत्रण के रूप में इस्तेमाल करें
प्रोटेक्टिव DNS सेवाएँ कनेक्शन बनने से पहले ही जाने-पहचाने दुर्भावनापूर्ण डोमेन का रिज़ॉल्यूशन ब्लॉक कर देती हैं। CISA और UK National Cyber Security Centre प्रोटेक्टिव DNS को फ़िशिंग, मैलवेयर, बॉटनेट, और रैनसमवेयर गतिविधि का असर घटाने के तरीक़े के रूप में बताते हैं।
उचित प्राइवेसी और रिटेंशन नियंत्रणों के साथ रिज़ॉल्वर लॉग इकट्ठा करें। DNS घटनाओं को एंडपॉइंट, आइडेंटिटी, और नेटवर्क सबूतों से जोड़ें। जब विश्लेषक अनुरोध करने वाले डिवाइस, यूज़र, और उसके बाद के कनेक्शन की पहचान कर सकें, तो कोई संदिग्ध क्वेरी ज़्यादा उपयोगी बन जाती है।
पूरे रास्ते को पैच करें
DNS सुरक्षा सिर्फ़ ख़ास DNS सॉफ़्टवेयर पर निर्भर नहीं करती। ऑपरेटिंग सिस्टम, राउटर, फ़ायरवॉल, रजिस्ट्रार, मैनेजमेंट पोर्टल, और ऑटोमेशन क्रेडेंशियल — ये सभी DNS के व्यवहार को प्रभावित कर सकते हैं।
2026 में, UK National Cyber Security Centre ने बताया कि APT28 ने DNS हाईजैकिंग और एडवरसरी-इन-द-मिडल गतिविधि को सक्षम करने के लिए कमज़ोर राउटर का इस्तेमाल किया। सीख उस अभियान से कहीं बड़ी है: कोई हमलावर ऑथॉरिटेटिव सर्वर से सीधे समझौता करने के बजाय आस-पास के इंफ़्रास्ट्रक्चर के ज़रिए DNS में हेरफेर कर सकता है।
टेक्नोलॉजी पेशेवरों को क्या जानना चाहिए
ज़्यादातर डेवलपर्स को DNS सर्वर चलाने की ज़रूरत नहीं, लेकिन उन्हें यह समझना चाहिए कि किसी एप्लिकेशन की उपलब्धता और पहचान उनके कोड तक अनुरोध पहुँचने से पहले ही शुरू हो जाती है।
क्लाउड और प्लेटफ़ॉर्म इंजीनियरों को जानना चाहिए कि कौन-सी सेवा ऑथॉरिटेटिव है, वर्कलोड कौन-से रिज़ॉल्वर इस्तेमाल करते हैं, प्राइवेट और पब्लिक ज़ोन कैसे इंटरैक्ट करते हैं, और क्षेत्रों में DNS कैसे विफल होता है। सुरक्षा टीमों को डोमेन प्रशासन को विशेषाधिकार-प्राप्त इंफ़्रास्ट्रक्चर मानना चाहिए और DNS लॉग को डिटेक्शन का हिस्सा बनाना चाहिए। लीडर्स को यह पता होना चाहिए कि अगर सामान्य प्रशासनिक अकाउंट अनुपलब्ध या समझौता किया गया हो, तो डोमेन को कौन रिकवर कर सकता है।
सबसे उपयोगी पहला सवाल सीधा है:
अगर आज हमारे DNS जवाब अनुपलब्ध या अविश्वसनीय हो जाएँ, तो कौन-सी सेवाएँ ठप हो जाएँगी—और अथॉरिटी को दोबारा कौन बहाल कर सकता है?
अगर कोई इसका भरोसे के साथ जवाब नहीं दे सकता, तो संगठन ने एक ऐसा सुरक्षा और रेज़िलिएंस अंतर खोज लिया है जिसे ठीक करना ज़रूरी है।
और गहराई से जानें
- NIST SP 800-81 Revision 3: Secure Domain Name System Deployment Guide — ऑथॉरिटेटिव DNS, रिकर्सिव रिज़ॉल्वर, DNSSEC, एन्क्रिप्टेड DNS, प्रोटेक्टिव DNS, और तैनाती सुरक्षा पर मौजूदा मार्गदर्शन। मार्च 2026 में प्रकाशित।
- CISA और NSA का प्रोटेक्टिव DNS पर मार्गदर्शन — बताता है कि DNS फ़िल्टरिंग दुर्भावनापूर्ण डोमेन के जोखिम को कैसे घटा सकती है।
- RFC 7873: Domain Name System Cookies — डिनायल-ऑफ़-सर्विस, एम्प्लिफ़िकेशन, फ़ोर्जरी, और कैश-पॉइज़निंग हमलों के ख़िलाफ़ सीमित सुरक्षा का वर्णन करता है।
- Windows DNS ज़ोन ट्रांसफ़र सुरक्षित करने पर Microsoft का मार्गदर्शन — Windows DNS ज़ोन ट्रांसफ़र को सीमित करने पर व्यावहारिक मार्गदर्शन।
- APT28 DNS हाईजैकिंग पर NCSC सलाह — समझौता किए गए आस-पास के इंफ़्रास्ट्रक्चर के ज़रिए DNS हेरफेर का 2026 का उदाहरण।