Skip to content

DNS Forwarding क्या है? यह कैसे काम करता है और क्यों महत्वपूर्ण है

DNS forwarding क्या है? जानें कि फ़ॉरवर्डर्स रिकर्सिव रिज़ॉल्वर्स से कैसे भिन्न हैं, कैशिंग और फ़ेलओवर कैसे काम करते हैं, और आधुनिक नेटवर्क में फ़ॉरवर्डिंग कहाँ उपयुक्त होती है।

Published 23 अक्टूबर 2026

What Is DNS Forwarding? How It Works and Why It Matters

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

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

विषय-सूची

DNS फ़ॉरवर्डिंग का वास्तव में क्या अर्थ है

स्थानीय हलकर्ता (local resolver) को एक मेलरूम फ्रंट डेस्क की तरह समझें। एक क्लाइंट नाम से वेबसाइट मांगता है, और हलकर्ता जांचता है कि क्या वह पहले से उत्तर जानता है। यदि इसके पास इसके कैश में कोई मान्य उत्तर है, तो यह उसे लौटा देता है। यदि नहीं, तो यह क्वेरी को अपस्ट्रीम DNS सर्वर, यानी forwarder को भेजता है, जो लुकअप को संभालता है और प्रतिक्रिया वापस करता है।

वह व्यवस्था दो कार्यों को अलग करती है। स्थानीय हलकर्ता (local resolver) नेटवर्क के क्लाइंट्स का सामना करता है और स्थानीय नियमों को लागू कर सकता है। अपस्ट्रीम हलकर्ता (upstream resolver) उन नामों को हल करने का काम करता है जिनका उत्तर स्थानीय सर्वर अपने कैश या स्थानीय डेटा से नहीं दे सकता है। इसलिए फॉरवर्डिंग एक आर्किटेक्चरल फ़ंक्शन है, न कि अपने आप में कोई सुरक्षा उत्पाद।

DNS फ़ॉरवर्डिंग को दर्शाने वाला एक आरेख जहाँ क्लाइंट क्वेरी सर्वर पर जाती है और फिर अपस्ट्रीम जाती है।

DNS का आगमन नवंबर 1983 में हुआ था, जब RFC 882 और RFC 883 ने बढ़ते हुए अनियंत्रित HOSTS.TXT मॉडल को बदलने के लिए एक पदानुक्रमित (hierarchical) नेमिंग सिस्टम पेश किया। DNS से पहले, प्रशासक मैन्युअल रूप से बनाए गए नाम-से-पता मैपिंग पर निर्भर रहते थे। नवंबर 1987 में, RFC 1034 और RFC 1035 ने मूल विशिष्टताओं को बदल दिया और आधुनिक DNS आर्किटेक्चर के लिए मूलभूत मानक बन गए, जैसा कि DNS इतिहास टाइमलाइन में दर्ज है।

आप फ़ॉरवर्डिंग का सामना कहाँ करेंगे

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

उपयोगी मानसिक मॉडल सरल है: स्थानीय हलकर्ता (local resolver) नियंत्रित फ्रंट डेस्क है; अपस्ट्रीम हलकर्ता विशेषज्ञ है जो पूर्ण लुकअप करता है। यह मॉडल किसी समस्या का पता लगाना भी आसान बनाता है। अपस्ट्रीम हलकर्ता अनुपलब्ध होने या त्रुटि लौटाने पर भी एक क्लाइंट सफलतापूर्वक फ्रंट डेस्क तक पहुंच सकता है।

क्लाइंट से उत्तर तक क्वेरी का अनुसरण करना

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

एक क्लाइंट डिवाइस से अंतिम उत्तर तक चरण-दर-चरण DNS फॉरवर्डिंग प्रक्रिया को दर्शाने वाला एक आरेख।

DNS शब्दावली में, फ़ॉरवर्डिंग में एक रिज़ॉल्वर शामिल होता है जो recursion-desired (RD) bit सेट के साथ एक प्रश्न भेजता है। वह बिट संकेत देता है कि प्राप्त करने वाले रिज़ॉल्वर से उस प्रश्न को हल करने के लिए कहा जा रहा है, न कि केवल उस अनुरोध के बिना पैकेट को रिले करने के लिए। RFC 7719 की शब्दावली परिभाषा अंधी पैकेट रिलेइंग से फ़ॉरवर्डिंग को अलग करती है।

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

दो संभावित रास्ते

  • कैश हिट: स्थानीय रिज़ॉल्वर एक मान्य कैश किया गया उत्तर लौटाता है। अपस्ट्रीम सर्वर उस लुकअप में शामिल नहीं है।
  • कैश मिस: स्थानीय रिज़ॉल्वर अपस्ट्रीम में प्रश्न भेजता है, प्रतिक्रिया प्राप्त करता है, और इसे क्लाइंट को लौटाता है।

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

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

फ़ॉरवर्डिंग रिकर्शन और अथॉरिटेटिव सर्विस से किस प्रकार भिन्न है

DNS फॉरवर्डिंग, रिकर्शन, प्रॉक्सीइंग और ऑथोरिटेटिव सर्विस अलग-अलग भूमिकाओं का वर्णन करते हैं। एक ही सिस्टम एक से अधिक भूमिकाएं निभा सकता है, लेकिन ये शब्द एक दूसरे के स्थान पर प्रयोग करने योग्य नहीं हैं। एक सामान्य फॉरवर्डिंग सेटअप में, स्थानीय सर्वर क्लाइंट्स को सेवा प्रदान करता है और कैश या नीतियों को बनाए रखता है; एक अपस्ट्रीम रिकर्सिव हलकर्ता (upstream recursive resolver) कैश चूक (cache misses) के लिए समाधान करता है।

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

तालिका का मुख्य अंतर यह है कि पूर्ण लुकअप कौन करता है। एक फॉरवर्डिंग हलकर्ता (forwarding resolver) अनुत्तरित क्वेरी को आगे भेजता है; एक रिकर्सिव हलकर्ता (recursive resolver) संभावित रूप से अधिकृत सर्वरों से पूछताछ करके समाधान को संभालता है। एक अधिकृत सर्वर (authoritative server) किसी क्लाइंट की ओर से पदानुक्रम (hierarchy) की खोज करने के बजाय उसके द्वारा प्रबंधित डोमेन के लिए रिकॉर्ड प्रदान करता है।

यह अंतर समस्या निवारण को क्यों बदल देता है

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

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

कंडीशनल फ़ॉरवर्डिंग, स्प्लिट होराइज़न और लूप रोकथाम

फॉरवर्डिंग के लिए हर अनुत्तरित क्वेरी को एक ही अपस्ट्रीम सर्वर पर भेजना आवश्यक नहीं है। Conditional forwarding के साथ, एक हलकर्ता (resolver) चुने गए डोमेन के लिए नामित सर्वर पर प्रश्न भेजता है। उदाहरण के लिए, एक नेटवर्क आंतरिक नामों के अनुरोधों को एक आंतरिक DNS सेवा की ओर निर्देशित कर सकता है और अन्य अनुरोधों को प्रबंधित रिकर्सिव हलकर्ता (managed recursive resolver) को भेज सकता है।

एक संबंधित विचार स्प्लिट-हराइज़न DNS है। यह एक नेटवर्क को इस आधार पर एक ही नाम के लिए अलग-अलग उत्तर लौटाने की अनुमति देता है कि अनुरोध कहाँ से आता है। किसी संगठन के भीतर का व्यक्ति एक आंतरिक उत्तर प्राप्त कर सकता है, जबकि एक बाहरी अनुरोधकर्ता एक अलग उत्तर प्राप्त करता है। स्थानीय रिज़ॉल्वर आंतरिक नामों को उपयुक्त पथ पर रखने के लिए एक निर्णय बिंदु बन जाता है।

एक पेशेवर कंप्यूटर पर काम कर रहा है जो स्क्रीन पर नेटवर्क इंफ्रास्ट्रक्चर आरेखों के साथ DNS फॉरवर्डिंग अवधारणाओं का प्रदर्शन कर रहा है।

कॉन्फ़िगरेशन में यह स्पष्ट होना चाहिए कि कौन सा रिज़ॉल्वर किस क्वेरी पाथ का स्वामी है। एक नियम जो गलत अपस्ट्रीम सर्वर को आंतरिक नाम भेजता है, वह बाहरी उत्तर दे सकता है, फ़ेल हो सकता है, या ऐसा परिणाम दे सकता है जो नेटवर्क के विभिन्न हिस्सों के बीच भिन्न हो।

रिज़ॉल्वर लूप्स को रोकना

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

कुछ नामों को एक स्पष्ट सीमा की भी आवश्यकता होती है। RFC 9539 home.arpa जैसे नेमस्पेस की ओर इशारा करता है जिन्हें उनके इच्छित स्थानीय दायरे से बाहर फ़ॉरवर्ड नहीं किया जाना चाहिए। एक रिज़ॉल्वर जो तब तक काम करता है जब तक कि दूसरा फ़ॉरवर्डर जोड़ा नहीं जाता, उसमें लूप आ सकता है; एक स्थानीय नाम जो सार्वजनिक रूप से रिज़ॉल्व होना शुरू होता है, उसे अधिक विशिष्ट फ़ॉरवर्डिंग या लोकल-ज़ोन नियम की आवश्यकता हो सकती है।

नीचे दिया गया वीडियो DNS फॉरवर्डिंग अवधारणाओं का एक और दृश्य परिचय प्रदान करता है।

कैशिंग और TTL फ़ॉरवर्डिंग प्रदर्शन को कैसे आकार देते हैं

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

प्रत्येक रिकॉर्ड का टाइम टू लाइव (TTL) उस मेमोरी पर सीमा तय करता है। ऑथॉरिटेटिव सर्वर TTL प्रकाशित करता है, और पथ के साथ कोई भी रिज़ॉल्वर कैश्ड उत्तर का पुनः उपयोग केवल तब तक कर सकता है जब तक वह वैध रहता है। छोटे TTL उत्तरों को ताज़ा रखते हैं लेकिन अपस्ट्रीम में अधिक प्रश्न भेजते हैं। लंबे TTL अपस्ट्रीम ट्रैफ़िक को कम करते हैं लेकिन इंफ्रास्ट्रक्चर परिवर्तन के बाद क्लाइंट्स के पास पुराने पते छोड़ सकते हैं।

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

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

औसत लेटेंसी से अधिक मापें

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

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

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

फ़ॉरवर्डिंग, रूट-हिंट्स रिकर्शन और एन्क्रिप्टेड DNS के बीच चयन करना

फ़ॉरवर्डिंग और रूट-हिंट्स पुनरावृत्ति (recursion) अलग-अलग लाभ और समझौते पेश करते हैं। फ़ॉरवर्डिंग के साथ, एक संगठन अनुत्तरित प्रश्नों को संभालने के लिए अपस्ट्रीम रिज़ॉल्वर्स का चयन करता है। यह स्थानीय संचालन को सरल बना सकता है और नीति को केंद्रीकृत कर सकता है, लेकिन यह नेटवर्क को चुने गए अपस्ट्रीम सेवाओं पर निर्भर बनाता है। रूट-हिंट्स पुनरावृत्ति के साथ, एक रिज़ॉल्वर स्वयं पुनरावृत्त लुकअप करता है, जो एकल अपस्ट्रीम पुनरावृत्ति सेवा पर निर्भरता को कम करता है लेकिन उस रिज़ॉल्वर पर अधिक रिज़ॉल्यूशन जिम्मेदारी डालता है।

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

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

पब्लिक WiFi को एक सुविचारित नीति की आवश्यकता है

पब्लिक WiFi ऑपरेटरों को Captive Portal पर भी विचार करना होगा। उपयोगकर्ताओं द्वारा साइन इन करने से पहले उपकरणों को पूर्व-प्रमाणीकरण (pre-authentication) नाम समाधान और कनेक्टिविटी जांच की आवश्यकता हो सकती है। एन्क्रिप्टेड DNS पोर्टल पहचान को जटिल बना सकता है या इसमें देरी कर सकता है, इसलिए ऑपरेटरों को यह तय करने की आवश्यकता है कि कौन से हलकर्ता (resolvers) स्वीकृत हैं, फॉलबैक कैसे काम करना चाहिए, और क्या कोई अपवाद आवश्यक हैं।

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

अपने नेटवर्क पर फ़ॉरवर्डिंग का उपयोग करना

फॉरवर्डिंग किसी संगठन द्वारा चुने गए अपस्ट्रीम सेवाओं पर कुछ DNS वर्कलोड को केंद्रित करती है। DNS-OARC के 'डे इन द लाइफ' डेटासेट का उपयोग करके किए गए मापों से पता चला है कि लगभग 99% रिकर्सिव रिज़ॉल्वर्स ने मध्यम क्वेरी वॉल्यूम उत्पन्न किया, जबकि लगभग 1% ने आक्रामक रूप से व्यवहार किया। उस छोटे समूह ने 2018 में देखे गए DNS ट्रैफिक का 98% और 2019 में 93% हिस्सा कवर किया; शोधकर्ताओं का अनुमान है कि इसमें 2018 में लगभग 8,300 रिज़ॉल्वर्स और 2019 में 14,000 से अधिक शामिल थे (अग्रेंसिव रिज़ॉल्वर व्यवहार का अध्ययन)। एक स्थानीय रिज़ॉल्वर अपस्ट्रीम रिकर्सिव सेवाओं को अनुरोध भेज सकता है जो उत्तरों को कैश और पुनः उपयोग करती हैं, लेकिन यह उनकी उपलब्धता और व्यवहार पर निर्भरता को केंद्रित करता है।

फ़ॉरवर्डिंग को तैनात करने या बदलने से पहले, जांच लें कि:

  • अपस्ट्रीम स्वतंत्र हैं: जहां डिज़ाइन अनुमति देता है वहां कम से कम दो फ़ॉरवर्डर्स कॉन्फ़िगर करें।
  • विफलताओं की एक परिभाषित प्रतिक्रिया होती है: टाइमआउट और पुनः प्रयास (retry) व्यवहार सेट करें, और जानें कि यदि अपस्ट्रीम प्रतिक्रिया नहीं देता है तो क्लाइंट को क्या प्राप्त होता है।
  • निगरानी में लक्षण शामिल हैं: SERVFAIL प्रतिक्रियाओं, टाइमआउट और प्रतिक्रिया विलंबता (latency) पर नज़र रखें।
  • गोपनीयता की अपेक्षाएं स्पष्ट हैं: निर्णय लें कि कौन सा अपस्ट्रीम रिज़ॉल्वर फ़ॉरवर्ड की गई क्वेरीज़ देख सकता है।

यदि DNS फ़िल्टरिंग आपकी अतिथि-नेटवर्क (guest-network) नीति का हिस्सा है, तो इसकी तुलना अपने व्यापक WiFi सामग्री फ़िल्टरिंग दृष्टिकोण से करें। फिर ऑडिट करें कि आपका नेटवर्क किस हलकर्ता (resolver) को फॉरवर्ड करता है और पुष्टि करें कि इसकी नीति, उपलब्धता और गोपनीयता स्थिति आपके इच्छानुसार है या नहीं।


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

Decide what your WiFi reaches, free for 30 days

Tell us which networks you run and who is on them. We map a policy to each one: guests, staff, students, residents and paid tiers. Then point one network at Shield and see what it stops for 30 days, before you pay anything. Running change control? We plan a pilot on one SSID with your team instead. No hardware, no agents on devices.

  1. We map your networksA Purple expert maps your networks, your venues and the people on each, and answers your questions on bypass, outages, data handling and integrations.
  2. You get a policy for each oneGuests, staff, students, residents and paid tiers, each with the policy it needs.
  3. You prove it, then get your tailored quote30 days free on one network, or a pilot on one SSID planned with your team, then Shield priced standalone or as an add-on to your Access plan.

Your policy map

Tell us your networks. We map a policy to each one.

A Purple expert comes back with a policy for every SSID you run, from the team that has run content filtering on WiFi since 2012 and runs WiFi for 80,000+ venues in 90 countries.