DNS Forwarding म्हणजे काय? ते कसे कार्य करते आणि ते का महत्वाचे आहे

DNS फॉरवर्डिंग ही अशी प्रक्रिया आहे ज्यामध्ये DNS रिझॉल्व्हर DNS हायराकीद्वारे थेट नावाचे रिझोल्यूशन करण्याऐवजी क्लायंटची क्वेरी दुसऱ्या DNS सर्व्हरकडे, म्हणजे फॉरवर्डरकडे पाठवते. स्थानिक रिझॉल्व्हर अजूनही त्याच्या कॅशमधून उत्तर देऊ शकतो आणि स्थानिक धोरणे लागू करू शकतो, तर गरज पडल्यास अपस्ट्रीम रिझॉल्व्हर पूर्ण शोध घेतो. परंतु जर तो अपस्ट्रीम सर्व्हर अयशस्वी झाला, तर DNS चा कोणता भाग खराब झाला आहे?

जेव्हा तुम्ही नेटवर्क कॉन्फिगर करत असता किंवा एखादी वेबसाइट का लोड होत नाही हे समजावून सांगण्याचा प्रयत्न करत असता, तेव्हा हा फरक महत्त्वाचा ठरतो. एक forwarding resolver केवळ पॅकेट्स पुढे पाठवत नाही: ते परिचित विनंत्यांना स्थानिक पातळीवर उत्तरे देऊ शकते, निवडलेल्या क्वेरी वेगवेगळ्या सर्व्हरवर निर्देशित करू शकते आणि वापरकर्त्याचा DNS ट्रॅफिक कोणता रिझॉल्व्हर पाहतो ते ठरवू शकते.

अनुक्रमणिका

• DNS Forwarding म्हणजे नेमके काय
  • तुम्हाला Forwarding कुठे आढळेल
• क्लायंटपासून उत्तरापर्यंतच्या क्वेरीचा मागोवा घेणे
  • दोन संभाव्य मार्ग
• Forwarding हे Recursion आणि Authoritative सर्व्हिसपेक्षा कसे वेगळे आहे
  • हा फरक ट्रबलशूटिंगमध्ये कसा बदल करतो
• Conditional Forwarding, Split Horizon आणि Loop Prevention
  • Resolver loops रोखणे
• Caching आणि TTL, Forwarding परफॉर्मन्स कसा ठरवतात
  • सरासरी लॅटन्सीपेक्षा अधिक मोजा
• Forwarding, Root-Hints Recursion आणि एन्क्रिप्टेड DNS मधील निवड करणे
  • पब्लिक WiFi साठी विचारपूर्वक पॉलिसीची आवश्यकता आहे
• तुमच्या नेटवर्कवर Forwarding चा वापर करणे

DNS फॉरवर्डिंगचा नेमका अर्थ काय आहे

लोकल रिव्हॉल्व्हरचा विचार मेलरूमच्या फ्रंट डेस्कप्रमाणे करा. क्लायंट नावाने वेबसाइट मागवतो आणि रिव्हॉल्व्हरला आधीच उत्तर माहित आहे की नाही हे तपासतो. जर त्याच्या कॅशेमध्ये वैध उत्तर असेल तर ते परत करते. तसे नसल्यास, ते अपस्ट्रीम DNS सर्व्हरकडे, म्हणजे फॉरवर्डर कडे क्वेरी पाठवते, जे लुकअप हाताळते आणि प्रतिसाद परत करते.

ती व्यवस्था दोन कामे वेगळी करते. लोकल रिव्हॉल्व्हर नेटवर्कच्या क्लायंटना सामोरे जातो आणि स्थानिक नियम लागू करू शकतो. अपस्ट्रीम रिव्हॉल्व्हर अशा नावांचे रिझोल्यूशन करण्याचे काम करतो ज्यांचे उत्तर लोकल सर्व्हर त्याच्या कॅशे किंवा लोकल डेटामधून देऊ शकत नाही. त्यामुळे फॉरवर्डिंग हे एक आर्किटेक्चरल कार्य आहे, ते आपोआप सुरक्षा उत्पादन ठरत नाही.

DNS चा उगम नोव्हेंबर 1983 मध्ये झाला, जेव्हा RFC 882 आणि RFC 883 ने वाढत्या प्रमाणात हाताळण्यास कठीण झालेल्या HOSTS.TXT मॉडेलची जागा घेण्यासाठी श्रेणीबद्ध नामकरण प्रणाली सादर केली. DNS पूर्वी, प्रशासक मॅन्युअली व्यवस्थापित केलेल्या नाव-ते-पत्ता मॅपिंगवर अवलंबून असत. नोव्हेंबर 1987 मध्ये, RFC 1034 आणि RFC 1035 ने मूळ तपशीलांची जागा घेतली आणि आधुनिक DNS आर्किटेक्चरसाठी पायाभूत मानके बनली, जसे की DNS इतिहास टाइमलाइन वर नोंदवले आहे.

तुम्हाला फॉरवर्डिंग कोठे आढळेल

होम राऊटर्स, एंटरप्राइझ नेटवर्क, सार्वजनिक WiFi, शाळा आणि क्लाउड वातावरण हे सर्व forwarding वापरू शकतात. एखादी संस्था कॅशिंग, लॉगिंग, अंतर्गत नावे किंवा ब्लॉकिंग नियमांवर स्थानिक नियंत्रण ठेवताना एका व्यवस्थापित recursive सेवेकडे सामान्य इंटरनेट लुकअप पाठवण्यासाठी याचा वापर करू शकते.

उपयुक्त मानसिक मॉडेल सोपे आहे: लोकल रिव्हॉल्व्हर हे नियंत्रित फ्रंट डेस्क आहे; अपस्ट्रीम रिव्हॉल्व्हर हा तज्ञ आहे जो पूर्ण लुकअप करतो. ते मॉडेल समस्या शोधणे देखील सोपे करते. अपस्ट्रीम रिव्हॉल्व्हर अनुपलब्ध असल्यास किंवा त्रुटी परत करत असला तरीही क्लायंट फ्रंट डेस्कपर्यंत यशस्वीरित्या पोहोचू शकतो.

क्लायंटपासून उत्तरापर्यंतच्या क्वेरीचा माग घेणे

एक सामान्य लुकअप तेव्हा सुरू होतो जेव्हा एखादे डिव्हाइस त्याच्या स्थानिक रिझॉल्व्हरला नाव विचारते. रिझॉल्व्हर प्रथम त्याची कॅशे तपासतो. साठवलेले उत्तर अद्याप वैध असल्यास, ते अपस्ट्रीम सर्व्हरशी संपर्क न साधता ते परत करू शकते. वापरण्यायोग्य कॅश केलेले उत्तर नसल्यास, रिझॉल्व्हर क्वेरी अपस्ट्रीम recursive रिझॉल्व्हरकडे फॉरवर्ड करतो.

DNS शब्दावलीमध्ये, फॉरवर्डिंगमध्ये recursion-desired (RD) bit सेटसह क्वेरी पाठवणारा रिझॉल्व्हर समाविष्ट असतो. तो बिट दर्शवतो की प्राप्त करणाऱ्या रिझॉल्व्हरला क्वेरीचे निराकरण करण्यास सांगितले जात आहे, केवळ त्या विनंतीशिवाय पॅकेट रिले करण्याऐवजी. RFC 7719 ची शब्दावली व्याख्या फॉरवर्डिंगला आंधळ्या पॅकेट रिलेइंगपासून वेगळे करते.

कॅश मिस झाल्यावर, अपस्ट्रीम रिकर्सिव्ह रिसोल्व्हर लूकअपचे काम करतो. ते स्वतःचे कॅश वापरू शकते किंवा उत्तरासाठी DNS हायरार्कीद्वारे क्वेरी करू शकते. प्रतिसादा नंतर फॉरवर्डिंग रिसोल्व्हरद्वारे क्लायंटकडे परत प्रवास करतो.

दोन संभाव्य मार्ग

• कॅशे हिट: स्थानिक रिझॉल्व्हर वैध कॅश केलेले उत्तर परत करतो. त्या लुकअपमध्ये अपस्ट्रीम सर्व्हरचा सहभाग नसतो.
• कॅशे मिस: स्थानिक रिझॉल्व्हर क्वेरी अपस्ट्रीम पाठवतो, प्रतिसाद प्राप्त करतो आणि तो क्लायंटला परत करतो.

हे हँडऑफ जबाबदाऱ्यांची एक उपयुक्त विभागणी देखील परिभाषित करते. स्थानिक रिझॉल्व्हर नेटवर्क विशिष्ट नियंत्रणे लागू करू शकते, लॉग ठेवू शकते, split-DNS नियम वापरू शकते किंवा DNSSEC व्हॅलिडेशन पॉलिसी लागू करू शकते. जेव्हा स्थानिक रिझॉल्व्हर त्याच्या कॅशे किंवा स्थानिक डेटावरून उत्तर देऊ शकत नाही, तेव्हा अपस्ट्रीम रिझॉल्व्हर recursive लुकअप करते.

ट्रबलशूटिंग क्लू: जर स्थानिक रिझॉल्व्हर क्लायंटना प्रतिसाद देत असेल परंतु त्याच्या कॅशेमध्ये उत्तर नसताना लुकअप अयशस्वी होत असतील, तर ऑथॉरिटेटिव्ह DNS सर्व्हिसमध्ये त्रुटी आहे असे गृहीत धरण्यापूर्वी फॉरवर्डिंग पाथ आणि अपस्ट्रीम रिस्पॉन्स तपासा.

फॉरवर्डिंग हे रिकर्शन आणि ऑथॉरिटेटिव्ह सर्व्हिसपेक्षा कसे वेगळे आहे

DNS फॉरवर्डिंग, रिकर्शन, प्रॉक्सिइंग आणि ऑथॉरिटेटिव्ह सर्व्हिस या वेगवेगळ्या भूमिकांचे वर्णन करतात. एकच सिस्टम एकापेक्षा जास्त भूमिका घेऊ शकते, परंतु या संज्ञा परस्परांशी बदलण्यायोग्य नाहीत. नेहमीच्या फॉरवर्डिंग सेटअपमध्ये, लोकल सर्व्हर क्लायंटना सेवा देतो आणि कॅशे किंवा धोरणे राखतो; अपस्ट्रीम रिकर्सिव्ह रिव्हॉल्व्हर कॅशे गहाळ झाल्यास रिझोल्यूशन करतो.

भूमिका	कोण सुरुवात करते	पूर्ण शोध (lookup) करते	Authoritative डेटा धरून ठेवते	सामान्य त्रुटीचे लक्षण
Forwarder	लोकल रीसोल्व्हर याला क्वेरी पाठवते	सामान्यतः, अपस्ट्रीम रिकर्सिव्ह रीसोल्व्हर म्हणून काम करताना	असावेच असे नाही	अपस्ट्रीम सर्व्हिसकडून टाइमआउट किंवा एरर
Recursive resolver	क्लायंट किंवा इतर रीसोल्व्हर रिझोल्यूशनची विनंती करतो	होय, कॅशे वापरून किंवा DNS हायराकीद्वारे क्वेरी करून	असावेच असे नाही	रिझोल्यूशन त्रुटी, टाइमआउट्स, किंवा अपयशी लुकअप्स
Proxy	क्लायंट किंवा सर्व्हिस याला ट्रॅफिक पाठवते	मूलभूतपणे नाही; प्रॉक्सी त्याच्या डिझाइननुसार रिक्वेस्ट पुढे पाठवते	नाही	प्रॉक्सी केलेली रिक्वेस्ट अयशस्वी होते किंवा गंतव्यस्थानापर्यंत पोहोचू शकत नाही
Authoritative server	रीसोल्व्हर ते सर्व्ह करत असलेल्या डोमेनसाठी क्वेरी करतो	नाही, ते त्याच्या झोनसाठी डेटा पुरवते	होय, ते सर्व्ह करत असलेल्या झोनसाठी	त्या झोनसाठी गहाळ, चुकीचे किंवा अनुपलब्ध रेकॉर्ड्स

तक्त्यातील मुख्य फरक म्हणजे पूर्ण लुकअप कोण करते. एक फॉरवर्डिंग रिव्हॉल्व्हर उत्तर न मिळालेली क्वेरी पुढे पाठवतो; एक रिकर्सिव्ह रिव्हॉल्व्हर संभाव्यतः ऑथॉरिटेटिव्ह सर्व्हर्सची चौकशी करून रिझोल्यूशन हाताळतो. ऑथॉरिटेटिव्ह सर्व्हर क्लायंटच्या वतीने हायलाइट शोधण्याऐवजी तो व्यवस्थापित करत असलेल्या डोमेनसाठी रेकॉर्ड प्रदान करतो.

हा फरक ट्रबलशूटिंग पद्धती का बदलतो

ऑथॉरिटेटिव्ह DNS इन्फ्रास्ट्रक्चर सामान्यपणे कार्य करत असतानाही, फॉरवर्डिंग रिझॉल्व्हर अपस्ट्रीम टाइमआउट, SERVFAIL किंवा कॅश केलेले उत्तर परत करू शकते जे आता योग्य नाही. अशा परिस्थितीत फक्त ऑथॉरिटेटिव्ह सर्व्हरचे ट्रबलशूटिंग केल्याने तुम्ही चुकीच्या मार्गावर जाऊ शकता. कोणत्या रिझॉल्व्हरला विनंती प्राप्त झाली, त्यात कॅश उत्तर होते का आणि पुढील हॉपवर काय घडले ते तपासा.

यामध्ये विश्वासाचे अवलंबित्व देखील आहे. RFC 7719 रिसोल्व्हरच्या शब्दावलीवर चर्चा करते, ज्यामध्ये फॉरवर्डर्स आणि रिकर्सिव्ह रिसोल्व्हर्समधील फरकाचा समावेश आहे. कॅश-पॉयझनिंग हल्ल्यांवरील संशोधन या भूमिकांमध्ये फरक करते कारण फॉरवर्ड वापरत असलेल्या अपस्ट्रीम रिसोल्व्हरच्या अखंडतेवर अवलंबून असतो. जर सामग्री नियंत्रणे डिझाइनचा भाग असतील, तर डिव्हाइस गंतव्यस्थानांशी कनेक्ट होण्यापूर्वी क्वेरींवर धोरण लागू करण्यासाठी नेटवर्क DNS फिल्टरिंग देखील वापरू शकते.

कंडिशनल फॉरवर्डिंग, स्प्लिट हॉरिझॉन आणि लूप प्रिव्हेन्शन

फॉरवर्डिंगद्वारे प्रत्येक न उत्तर दिलेल्या क्वेरीला एकाच अपस्ट्रीम सर्व्हरकडे पाठवण्याची गरज नसते. Conditional forwarding सह, एक रिव्हॉल्व्हर निवडलेल्या डोमेन्ससाठीच्या क्वेरी एका निर्दिष्ट सर्व्हरकडे पाठवतो. उदाहरणार्थ, एखादे नेटवर्क अंतर्गत नावांच्या विनंत्या अंतर्गत DNS सेवेकडे निर्देशित करू शकते आणि इतर विनंत्या व्यवस्थापित रिकर्सिव्ह रिव्हॉल्व्हरकडे पाठवू शकते.

याशी संबंधित एक कल्पना म्हणजे स्प्लिट-होरायझन DNS. हे विनंती कोठून येते यानुसार नेटवर्कला एकाच नावासाठी वेगवेगळी उत्तरे परत करू देते. संस्थेतील एखाद्या व्यक्तीला अंतर्गत उत्तर मिळू शकते, तर बाहेरील विनंतीकर्त्याला वेगळे उत्तर मिळू शकते. स्थानिक रिझॉल्व्हर हा अंतर्गत नावे योग्य मार्गावर ठेवण्यासाठी एक निर्णय बिंदू बनतो.

प्रत्येक क्वेरी पाथवर कोणत्या रिझॉल्व्हरची मालकी आहे हे कॉन्फिगरेशनद्वारे स्पष्ट केले पाहिजे. चुकीच्या अपस्ट्रीम सर्व्हरवर अंतर्गत नाव पाठवणारा नियम बाह्य उत्तर, रिझोल्यूशनमधील अयशस्वीता किंवा नेटवर्कच्या वेगवेगळ्या भागांमध्ये भिन्न परिणाम दर्शवू शकतो.

रिझॉल्व्हर लूप रोखणे

Forwarding loop तेव्हा घडते जेव्हा एक रिझॉल्व्हर दुसऱ्या रिझॉल्व्हरला एक क्वेरी पाठवतो जो शेवटी ती पुन्हा पहिल्याकडेच पाठवतो. ती क्वेरी सर्व्हरदरम्यान फिरत राहू शकते, ज्यामुळे वारंवार विनंत्या, टाइमआउट्स आणि संसाधने संपण्याची समस्या उद्भवू शकते. याचे निवारण म्हणजे forwarding मार्ग मॅप करणे आणि कोणतीही रिझॉल्व्हर साखळी आधीच्या सर्व्हरकडे परत निर्देशित करत नाही याची खात्री करणे होय.

काही नावांना स्पष्ट सीमेची देखील आवश्यकता असते. RFC 9539 home.arpa सारख्या नेमस्पेसकडे निर्देश करते ज्या त्यांच्या इच्छित स्थानिक व्याप्तीपलीकडे फॉरवर्ड केल्या जाऊ नयेत. दुसरा फॉरवर्डर जोडेपर्यंत कार्य करणाऱ्या रिझॉल्व्हरमध्ये लूप आला असू शकतो; सार्वजनिकपणे निराकरण होण्यास सुरुवात झालेल्या स्थानिक नावाला अधिक विशिष्ट फॉरवर्डिंग किंवा लोकल-झोन नियमांची आवश्यकता असू शकते.

खालील व्हिडिओ DNS फॉरवर्डिंग संकल्पनांची आणखी एक दृश्य ओळख प्रदान करतो.

कॅशिंग आणि TTL फॉरवर्डिंग परफॉर्मन्स कसा ठरवतात

फॉरवर्डर्सचे कॅश एखाद्या उपयुक्त मध्यस्थाच्या मेमरीसारखे कार्य करते: एकदा अपस्ट्रीमवरून उत्तर मिळवले की, ते पुढील समान प्रश्नाचे उत्तर स्वतःच देऊ शकते. हे एकच वर्तन फॉरवर्डिंग परफॉर्मन्ससाठी काय करते ते स्पष्ट करते. प्रत्येक कॅश हिट अपस्ट्रीम रिझॉल्व्हरची फेरी कमी करतो. प्रत्यक्ष लुकअप सुरू होण्यापूर्वी प्रत्येक मिस एक फेरी वाढवतो.

प्रत्येक रेकॉर्डची टाइम टू लिव्ह (TTL) त्या मेमरीवर मर्यादा घालते. ऑथॉरिटेटिव्ह सर्व्हर TTL प्रकाशित करतो आणि मार्गातील कोणताही रिझॉल्व्हर कॅश केलेले उत्तर ते वैध असेपर्यंतच पुन्हा वापरू शकतो. लहान TTL मुळे उत्तरे ताजी राहतात परंतु अपस्ट्रीममध्ये अधिक क्वेरी पाठवल्या जातात. मोठे TTL अपस्ट्रीम ट्रॅफिक कमी करतात परंतु इन्फ्रास्ट्रक्चर बदलांनंतर क्लायंटकडे जुने पत्ते राहू शकतात.

कॅशिंग देखील मार्गावर टप्प्याटप्प्याने जमा होते. क्लायंटचे कॅश, फॉरवर्डर्सचे कॅश किंवा अपस्ट्रीम रिझॉल्व्हरचे कॅशद्वारे क्वेरी पूर्ण केली जाऊ शकते आणि प्रत्येक लेयर स्वतःचे TTL काउंटडाउन चालवते. जेव्हा एखादा वापरकर्ता जुन्या उत्तराची तक्रार करतो, तेव्हा तो फिक्स ही गोष्ट कोणत्या लेयरने धरून ठेवली आहे यावर अवलंबून असतो, त्यामुळे ट्रबलशूटिंग दरम्यान जवळ असणारे काहीही फ्लश करण्याऐवजी प्रत्येक कॅशकडे वेगळा संशयित म्हणून पहा.

सरासरी लेटन्सीपेक्षा अधिक गोष्टी मोजा

सरासरी लुकअप वेळ अशा समस्या लपवू शकते ज्या इतर वापरकर्त्यांपेक्षा काही ठराविक वापरकर्त्यांवर किंवा क्वेरींवर अधिक परिणाम करतात. कॅशे-हिट रेशिओ, मेडियन आणि टेल लुकअप लॅटन्सी, अपस्ट्रीम टाइमआउट दर, आणि निगेटिव्ह-कॅशे वर्तन ट्रॅक करा. हे उपाय स्लो अपस्ट्रीम सर्व्हिस आणि कॅशे संधी चुकवणाऱ्या किंवा अयशस्वी लुकअप्स अयोग्यरित्या हाताळणाऱ्या forwarder मधील फरक ओळखण्यास मदत करतात.

DNSSEC आणखी एक अडचण निर्माण करते. एक व्हॅलिडेटिंग रिझॉल्व्हर उत्तराच्या वरच्या बाजूला स्वाक्षऱ्या आणि की मिळवतो, त्यामुळे स्वाक्षरी केलेल्या नावांवर कॅशे मिस होणे हे स्वाक्षरी नसलेल्यांपेक्षा जास्त महाग पडते. कॅश केलेली व्हॅलिडेट केलेली उत्तरे ते वारंवार होणारे काम टाळतात, ज्यामुळे हिट रेशो व्हॅलिडेटिंग मार्गांवर अधिक महत्त्वाचा ठरतो.

दिलेल्या नेटवर्कवर लुकअप वेळेचा अंदाज कोणताही एक टप्पा लावू शकत नाही. परिणाम प्रत्येक लेयरवरील कॅशची स्थिती, अपस्ट्रीम प्रतिसाद क्षमता, व्हॅलिडेशनचे काम, ट्रान्सपोर्ट सेटअप आणि प्रतिसाद न देणाऱ्या फॉरवर्डरा नंतरचे पुन्हा प्रयत्न यावर अवलंबून असतो. एक चांगला फॉरवर्डर रिस्पॉन्स कोड, ट्रंकेशन वर्तन, DNSSEC रेकॉर्ड आणि फ्लॅग बदल न करता पुढे पाठवतो, जेणेकरून क्लायंटला ऑथॉरिटेटिव्ह बाजूने पाठवलेले उत्तर दिसते.

फॉरवर्डिंग, रूट-हिंट्स रिकर्शन आणि एन्क्रिप्टेड DNS दरम्यान निवड करणे

फॉरवर्डिंग आणि रूट-हिंट्स रिकर्शन वेगवेगळ्या तडजोडी करतात. फॉरवर्डिंगसह, एखादी संस्था न उलगडलेल्या क्वेरी हाताळण्यासाठी अपस्ट्रीम रिझॉल्व्हर्स निवडते. ते स्थानिक ऑपरेशन्स सुलभ करू शकते आणि धोरण केंद्रित करू शकते, परंतु यामुळे नेटवर्क निवडलेल्या अपस्ट्रीम सेवांवर अवलंबून राहते. रूट-हिंट्स रिकर्शनसह, एक रिझॉल्व्हर स्वतःच लूपअपची पुनरावृत्ती करतो, ज्यामुळे एकाच अपस्ट्रीम रिकर्सिव्ह सेवेवरील अवलंबित्व कमी होते परंतु त्या रिझॉल्व्हरवर रिझोल्यूशनची अधिक जबाबदारी येते.

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

एनक्रिप्टेड DNS ही निवड कमी सरळ बनवते. DNS over TLS आणि DNS over QUIC ट्रांझिटमधील DNS ट्रॅफिकचे संरक्षण करू शकतात, परंतु महत्त्वाचा प्रश्न असा आहे की एनक्रिप्शन कोठे संपते. जर क्लायंट क्वेरी थेट बाह्य रिझॉल्व्हरवर एनक्रिप्ट करत असेल, तर स्थानिक फॉरवर्डरला वापरण्यायोग्य डोमेन क्वेरी दिसणार नाही. जर एनक्रिप्शन मान्यताप्राप्त एंटरप्राइझ रिझॉल्व्हरवर समाप्त झाले, तर ते रिझॉल्व्हर तरीही नेटवर्क धोरणे लागू करू शकते आणि क्वेरी अपस्ट्रीम फॉरवर्ड करू शकते.

सार्वजनिक WiFi ला एका विचारांती ठरवलेल्या पॉलिसीची आवश्यकता असते

पब्लिक WiFi ऑपरेटर्सना Captive Portal चा देखील विचार करावा लागतो. वापरकर्ते साइन इन करण्यापूर्वी उपकरणांना पूर्व-प्रमाणीकरण नाव रिझोल्यूशन आणि कनेक्टिव्हिटी तपासणीची आवश्यकता असू शकते. एनक्रिप्टेड DNS मुळे पोर्टल शोधणे गुंतागुंतीचे किंवा विलंब करू शकते, म्हणून ऑपरेटर्सना कोणते रिव्हॉल्व्हर मंजूर आहेत, फॉलबॅक कसा कार्य करेल आणि काही अपवाद आवश्यक आहेत का हे ठरवणे आवश्यक आहे.

संरक्षक DNS सेवा निवडलेल्या रिसोल्युशन पाथमध्ये राहू शकते आणि कनेक्शन सुरू होण्यापूर्वी लूकअपचे मूल्यमापन करू शकते. Purple Shield हे व्हेन्यू आणि अतिथी WiFi नेटवर्कसाठी डिझाइन केलेले आहे, ज्यामध्ये श्रेणी-आधारित सामग्री फिल्टरिंग, DNS स्तरावर थ्रेट ब्लॉकिंग आणि धोरणे आहेत जी नेटवर्कद्वारे व्यवस्थापित केली जाऊ शकतात. हे एक स्वतंत्र सेवा म्हणून तैनात केले जाऊ शकते किंवा Purple Access नेटवर्कसह एकत्रित केले जाऊ शकते. व्यापक वेब ट्रॅफिक नियंत्रणांविरुद्ध DNS नियंत्रणांचे वजन करणाऱ्या टीमसाठी, सुरक्षित वेब गेटवे विहंगावलोकन अंमलबजावणीच्या वेगवेगळ्या स्तराचे वर्णन करते.

तुमच्या नेटवर्कवर फॉरवर्डिंगचा वापर करणे

फॉरवर्डिंगमुळे संस्थेने निवडलेल्या अपस्ट्रीम सेवांवर काही DNS वर्कलोड केंद्रित होतो. DNS-OARC च्या डे इन द लाइफ डेटासेटचा वापर करून केलेल्या मापनात असे आढळून आले की अंदाजे 99% रिकर्सिव्ह रिसोल्व्हर्सने मध्यम क्वेरी व्हॉल्यूम जनरेट केला, तर सुमारे 1% रिसोल्व्हर्सने आक्रमक वर्तन केले. त्या लहान गटाचा 2018 मधील निरीक्षण केलेल्या DNS रहदारीमध्ये 98% आणि 2019 मध्ये 93% वाटा होता; संशोधकांच्या मते यामध्ये सुमारे 2018 मध्ये 8,300 रिसोल्व्हर्स आणि 2019 मध्ये 14,000 पेक्षा जास्त रिसोल्व्हर्स समाविष्ट होते (आक्रमक रिसोल्व्हर वर्तनाचा अभ्यास). स्थानिक रिसोल्व्हर अपस्ट्रीम रिकर्सिव्ह सेवांना विनंत्या पाठवू शकतो ज्या उत्तरे कॅश करतात आणि पुन्हा वापरतात, परंतु ते त्यांच्या उपलब्धतेवर आणि वर्तनावरील अवलंबित्व केंद्रित करते.

फॉरवर्डिंग उपयोगात आणण्यापूर्वी किंवा बदलण्यापूर्वी, पुढील गोष्टी तपासा:

• अपस्ट्रीम स्वतंत्र आहेत: जिथे डिझाइन अनुमती देते तिथे किमान दोन फॉरवर्डर कॉन्फिगर करा.
• अपयशांसाठी परिभाषित प्रतिसाद आहे: टाइमआउट आणि रीबायहेवियर सेट करा, आणि अपस्ट्रीमने प्रतिसाद न दिल्यास क्लायंटला काय मिळते ते जाणून घ्या.
• मॉनिटरिंगमध्ये लक्षणांचा समावेश होतो: SERVFAIL प्रतिसाद, टाइमआउट्स आणि प्रतिसादातील विलंब (लेटन्सी) यावर लक्ष ठेवा.
• गोपनीयतेच्या अपेक्षा स्पष्ट आहेत: कोणता अपस्ट्रीम रिझॉल्व्हर फॉरवर्ड केलेल्या क्वेरी पाहू शकतो ते ठरवा.

DNS फिल्टरिंग हा तुमच्या अतिथी-नेटवर्क धोरणाचा भाग असल्यास, त्याची तुलना तुमच्या व्यापक WiFi कंटेंट फिल्टरिंग दृष्टिकोनाशी करा. नंतर तुमचे नेटवर्क कोणत्या रिव्हॉल्व्हरकडे फॉरवर्ड करते याचे ऑडिट करा आणि त्याचे धोरण, उपलब्धता आणि गोपनीयता स्थिती तुमच्या इच्छेनुसार असल्याची खात्री करा.

---

Purple Shield डिव्हाइस कनेक्ट होण्यापूर्वी DNS लुकअप्स तपासते आणि वेन्यू तसेच गेस्ट WiFi नेटवर्कसाठी कंटेंट फिल्टरिंग आणि थ्रेट ब्लॉकिंग प्रदान करते. Forwarding त्या नियंत्रणांना कसे समर्थन देऊ शकते याचे तुम्ही पुनरावलोकन करत असल्यास, त्याचे टप्प्याटप्प्याने उपयोजन पर्याय शोधण्यासाठी Purple Shield ला भेट द्या.