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

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

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

अनुक्रमणिका

• रिफरसिव DNS रिसोल्व्हर तुमच्या डिव्हाइससाठी काय करतो
  • लुकअपमागील भूमिका
• रिकर्सिव्ह आणि ऑथॉरिटेटिव्ह DNS सर्व्हर्सची तुलना
  • ऑपरेटर भूमिकांचे विलीनीकरण न करता ओव्हरलॅप करू शकतात
• रिकर्सिव्ह लुकअप DNS हायटारकी कशी पार करतो
  • रिक्वेस्ट आणि उत्तराचे अनुसरण करा
  • कॅश केलेले उत्तर देखील वैध उत्तरच असते
• कॅशिंग, TTL आणि बदल होण्यासाठी लागणारा वेळ
  • पॉलिसी बदलांपासून रेकॉर्ड बदल वेगळे ठेवा
• रिसोल्व्हरवर फिल्टरिंग आणि सुरक्षा
  • कंटेंट फिल्टरिंग अ‍ॅक्सेसचे नियम सेट करते
  • थ्रेट डिफेन्स गंतव्यस्थानाचे मूल्यांकन करते
  • DNSSEC अस्सलता तपासते, सुरक्षा नाही
• आउटेज, जुनी उत्तरे आणि सामान्य गैरसमज
  • उपलब्धता आणि सुरक्षेसाठी स्पष्ट पर्यायांची आवश्यकता असते
  • ऑपरेशनल चुकांना कारणीभूत ठरणारे गृहीतके
• बदल करण्यापूर्वी तुमचे नेटवर्क कोणता रिसोल्व्हर वापरते याची पुष्टी करा
  • रोलआउट करण्यापूर्वी मार्ग तपासा

रिकर्सिव्ह DNS रिझॉल्व्हर तुमच्या डिव्हाइससाठी काय करतो

एक recursive DNS resolver डिव्हाइससाठी DNS उत्तरे शोधतो, अगदी हॉटेल कॉन्सीर्जसारखे जे पाहुण्याला काउंटरवरून काउंटरवर पाठवण्याऐवजी स्वतः वेगवेगळ्या विभागांशी संपर्क साधतात. पाहुणा प्रश्न विचारतो आणि उत्तराची अपेक्षा करतो, शोध सुरू ठेवण्यासाठी दिशानिर्देशांची नाही.

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

लुकअपमागील भूमिका

• क्लायंट: DNS उत्तराची विचारणा करणारे डिव्हाइस किंवा ॲप्लिकेशन.
• रिकर्सिव्ह रिझॉल्व्हर: ते उत्तर शोधण्यासाठी आणि परत करण्यासाठी जबाबदार असलेली सर्व्हिस.
• ऑथॉरिटेटिव्ह सर्व्हर: विनंती केलेल्या डोमेनसाठी अधिकृत DNS रेकॉर्ड प्रकाशित करणारा सर्व्हर.

कॉन्सिएर्जचे उदाहरण या जबाबदाऱ्या वेगळ्या करणे सोपे करते.

यशस्वी अ‍ॅड्रेस लुकअपसाठी, डिव्हाइसला IP अ‍ॅड्रेस आणि time-to-live मिळते, ज्याचे सहसा संक्षिप्त रूप TTL असे होते. ते मूल्य कॅशिंग सिस्टीमला उत्तर किती काळ पुन्हा वापरता येईल हे सांगते. त्यानंतर ब्राऊझर गंतव्यस्थानाशी संपर्क सुरू करण्यासाठी त्या अ‍ॅड्रेसचा वापर करू शकतो.

रिकर्सिव्ह म्हणजे अनंत पुनरावृत्ती असा होत नाही. ते रिझॉल्व्हर स्वीकारत असलेली जबाबदारी दर्शवते: क्लायंटसाठी अंतिम उत्तर शोधणे, किंवा तसे करण्यात अयशस्वी झाल्यास योग्य त्रुटी (error) परत करणे.

हॉटेलमधील पाहुण्याला सहसा यातले काहीही घडत असल्याचे माहित नसते. त्यांना रूट सर्व्हर निवडण्याची किंवा वेबसाइटचे DNS कोण होस्ट करते हे समजून घेण्याची आवश्यकता नसते.

एक उपयुक्त आकलन तपासणी सोपी आहे: तुमचे डिव्हाइस पत्ता विचारते, रिझॉल्व्हर तो शोधतो आणि तुमचा ब्राउझर कनेक्शन सुरू करण्यासाठी तो वापरतो.

रिकर्सिव्ह आणि ऑथॉरिटेटिव्ह DNS सर्व्हरची तुलना

रिकर्सिव्ह रिझॉल्व्हर विरुद्ध ऑथॉरिटेटिव्ह सर्व्हर

निकष	रिकर्सिव्ह रिसॉल्व्हर	अधिकृत सर्व्हर
मुख्य काम	इतर सर्व्हर्सना प्रश्न विचारून क्लायंटसाठी उत्तरे शोधतो	ते ज्या डोमेनसाठी जबाबदार आहे त्यांचे अधिकृत रेकॉर्ड प्रकाशित करतो
उत्तरे कोठून येतात	त्याचे कॅशे किंवा अपस्ट्रीम DNS सर्व्हर्स	त्याचे स्वतःचे झोन रेकॉर्ड्स
ठराविक ऑपरेटर	इंटरनेट प्रदाता, सार्वजनिक रिसॉल्व्हर सेवा, नेटवर्क मालक	डोमेन मालक किंवा होस्टिंग प्रदाता
डिव्हाइसद्वारे थेट संपर्क साधला जातो	होय	सामान्यतः नाही; रिसॉल्व्हर्स त्याच्याशी संपर्क साधतात
इतर डोमेनसाठी उत्तरे कॅशे करतो	होय, TTL आणि स्थानिक कॅशे नियमांच्या अधीन राहून	नाही, त्याच्या अधिकृत भूमिकेचा भाग म्हणून नाही

मुख्य फरक म्हणजे माहिती मिळवणे विरुद्ध ऑथॉरिटी. रिकर्सिव्ह रिझॉल्व्हर दुसऱ्या कोणासाठी तरी माहिती मिळवतो. ऑथॉरिटेटिव्ह सर्व्हर त्याच्या जबाबदारीखालील डोमेनसाठी माहिती प्रकाशित करतो.

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

ऑपरेटर्स भूमिकांचे विलीनीकरण न करता त्या ओव्हरलॅप करू शकतात

इंटरनेट प्रदाता सबस्कॉईबर्ससाठी रिकर्सिव्ह DNS चालवू शकतो, तर होस्टिंग प्रदाता ग्राहकांसाठी ॲथॉरिटेटिव्ह DNS प्रकाशित करतो. नेटवर्क मालक कर्मचाऱ्यांच्या उपकरणांसाठी अंतर्गत रिझॉल्व्हर देखील चालवू शकतो.

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

फॉरवर्डिंग आणखी एक फरक जोडते. स्थानिक DNS सर्व्हर स्वतः श्रेणीशी संपर्क साधण्याऐवजी अपस्ट्रीम रिझॉल्व्हरकडे विनंत्या पाठवू शकतो. DNS फॉरवर्डिंग समजून घेतल्याने तुम्हाला कोणती सर्व्हिस बाह्य लुकअप करते हे ओळखण्यास मदत होते.

ॲथॉरिटेटिव्ह सर्व्हर सहसा अभ्यागतांचा कंटेंट-फिल्टरिंग चेकपॉइंट नसतो. तो अभ्यागताचे नेटवर्क नियम लागू करण्याऐवजी डोमेनचे रेकॉर्ड्स प्रकाशित करतो.

निदानात्मक प्रश्न: हा सर्व्हर ज्या रेकॉर्ड्ससाठी जबाबदार आहे त्यावरून उत्तर देत आहे, की क्लायंटच्या वतीने रेकॉर्ड्स शोधत आहे?

DNS लेबल असलेला प्रत्येक सर्व्हर एकच काम करतो असे गृहीत धरण्यापेक्षा तो प्रश्न विचारणे अधिक उपयुक्त आहे.

रिकर्सिव्ह लुकअप DNS श्रेणीमध्ये कसा कार्य करतो

जेव्हा डिव्हाइस किंवा त्याच्या रिझॉल्व्हरकडे उत्तर देण्यासाठी आवश्यक माहिती नसते, तेव्हा www.example.com साठीचा लुकअप विचारात घ्या.

डिव्हाइस त्याच्या resolver ला अंतिम निकालासाठी विचारत एक recursive query पाठवते. Resolver सहसा अपस्ट्रीममध्ये iterative queries करते: रूट आणि टॉप-लेव्हल-डोमेन सर्व्हर्स रेफरल्स प्रदान करतात, तर अथॉरिटेटिव्ह सर्व्हर विनंती केलेले रेकॉर्ड प्रदान करतो.

हा आकृती वैयक्तिक देवाणघेवाणीपूर्वीचा एकूण प्रवास दाखवतो.

विनंती आणि उत्तराचे अनुसरण करा

1. डिव्हाइस त्याच्या कॉन्फिगर केलेल्या रिसॉल्व्हरशी संपर्क साधते. ते वेबसाइटचे नाव पाठवते कारण गंतव्यस्थानाशी संपर्क साधण्यापूर्वी त्याला पत्त्याची आवश्यकता असते.

2. रिसॉल्व्हर त्याचे कॅशे तपासते. वापरण्यायोग्य कॅशे केलेले उत्तर शोध त्वरित समाप्त करते. रिसॉल्व्हर पुन्हा वापरू शकेल अशा माहितीसाठी अपस्ट्रीम सर्व्हर्सना विचारण्याचे कोणतेही कारण नाही.

3. कॅशे मिस झाल्यास, ते रूट सर्व्हरला विचारते. रूट सर्व्हर त्याला संबंधित टॉप-लेव्हल डोमेनसाठी (या प्रकरणात .com) जबाबदार असलेल्या सर्व्हर्सकडे निर्देशित करतो.

4. ते .com सर्व्हरला विचारते. तो सर्व्हर example.com साठी अधिकृत नाव सर्व्हर्स ओळखतो, ज्यामुळे शोध डोमेनच्या नियुक्त प्राधिकरणांपर्यंत मर्यादित होतो.

5. ते अधिकृत सर्व्हरला प्रश्न विचारते. अधिकृत सर्व्हर विनंती केलेला पत्ता रेकॉर्ड आणि त्याचा TTL (सेकंदांमध्ये व्यक्त केलेला) परत करतो.

6. ते उत्तर साठवते आणि परत करते. रिसॉल्व्हर पुन्हा वापरण्यायोग्य प्रत राखून ठेवतो आणि निकाल डिव्हाइसवर पाठवतो.

7. नंतरच्या विनंत्या ती कॅशे केलेली प्रत वापरू शकतात. उत्तर वापरण्यायोग्य असेपर्यंत, रिसॉल्व्हरला त्याच नावासाठी आणि रेकॉर्ड प्रकारासाठी अपस्ट्रीम प्रवास पुनरावृत्ती करण्याची आवश्यकता नाही.

रचना जबाबदारीचे विभाजन करते. रूट सर्व्हर्स टॉप-लेव्हल-डोमेन ॲथॉरिटी ओळखतात, त्या ॲथॉरिटी डोमेन नेम सर्व्हर्स ओळखतात आणि डोमेन प्रशासक गंतव्य रेकॉर्ड्स व्यवस्थापित करतात.

कॅश केलेले उत्तर हे अजूनही एक वैध उत्तर असते

रिझॉल्व्हरचे उत्तर सहसा non-authoritative असते. याचा अर्थ ते डोमेनचे ॲथॉरिटी म्हणून उत्तर देण्याऐवजी माहिती पुढे पाठवत आहे, उत्तर अविश्वासार्ह आहे असा त्याचा अर्थ होत नाही.

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

स्थानिक कॅश नियम देखील महत्त्वाचे आहेत. RIPE 91 मधील APNIC च्या नोंदी सामान्यतः आढळणाऱ्या रिझॉल्व्हर कमाल कॅश टायमर्सची ओळख पटवतात जसे की 6 तास, 12 तास, 24 तास आणि 7 दिवस, जे हे दर्शवते की प्रशासकांनी प्रत्येक रिझॉल्व्हर समान कॅश मर्यादा पाळतो असे गृहीत धरू नये.

लुकअप प्रक्रियेच्या दुसऱ्या दृश्यासाठी, हा व्हिडिओ DNS रिझोल्यूशनचे अनुसरण करतो.

कॅशिंग, TTL आणि बदलासाठी लागणारा वेळ

एखादे डोमेन ९:०० वाजता ब्लॉक केले जाते आणि त्याच नेटवर्कवरील लॅपटॉप ९:४० वाजता ते उघडतो. हा फरक पुनर्वापरामुळे येतो. TTL हे पार्किंग तिकिटावरील एक्सपायरी वेळेसारखे कार्य करते: ते अपस्ट्रीमवर परत जाऊन पुन्हा विचारण्यापूर्वी साठवलेले उत्तर किती काळ देत राहू शकते हे resolver ला सांगते.

सामान्य कॅश केलेल्या रेकॉर्डसाठी, महत्त्वाची गोष्ट म्हणजे उर्वरित आयुष्य. रिझॉल्व्हरचा कमाल कॅश टाइमर ते आयुष्य कमी करू शकतो, तर स्थानिक पातळीवर लागू केलेले किमान ते वाढवू शकते. RIPE 91 मधील APNIC च्या नोंदींनुसार, निरीक्षण केलेले रिझॉल्व्हर कमाल 6 तास, 12 तास, 24 तास आणि 7 दिवस समाविष्ट करतात. या सेटिंग्ज रेकॉर्डची ताजेपणा संचलित करतात. जेव्हा फिल्टरिंग डिझाइन वर्तमान पॉलिसी तपासण्याऐवजी DNS उत्तर रिफ्रेश करण्यावर अवलंबून असते, तेव्हाच ब्लॉकला किती वेळ लागतो हे ते ठरवतात.

कॅश सेटिंग्ज आणि नवीन ब्लॉकसाठी त्यांचा काय अर्थ आहे

कॅश सेटिंग	सामान्य मूल्य	नवीन ब्लॉक किंवा बदलावर होणारा परिणाम
शून्य सेकंदांचे TTL	पुन्हा वापरण्यायोग्य लाइफटाइम नाही	सामान्य TTL हँडलिंग अंतर्गत, पुढील रिक्वेस्ट अपस्ट्रीम लुकअप ट्रिगर करते
शॉर्ट TTL	सेकंद ते मिनिटे	प्रत्येक रिफ्रेश नंतर लवकरच रेकॉर्ड बदल दिसू लागतात
रिसोल्व्हर मॅक्सिमम कॅश टायमर	6 तास	ज्या रेकॉर्डचे TTL जास्त वेळ चालते त्यांच्यासाठी रिटेंशन मर्यादा ठरवते
रिसोल्व्हर मॅक्सिमम कॅश टायमर	12 तास	दीर्घ रेकॉर्ड TTLs ला अर्ध्या दिवसावर संक्षिप्त करते
रिसोल्व्हर मॅक्सिमम कॅश टायमर	24 तास	उत्तर रात्रभर, पूर्ण एका दिवसापर्यंत टिकून राहू देते
रिसोल्व्हर मॅक्सिमम कॅश टायमर	7 दिवस	केवळ जेथे रेकॉर्ड TTL देखील अनुमती देते तेथेच आठवडाभर टिकून राहण्याची अनुमती देते

रेकॉर्डमधील बदल पॉलिसीमधील बदलांपासून वेगळे ठेवा

समजा, रिझॉल्व्हरने जुने उत्तर कॅश केल्यानंतर एका मिनिटाने साइटचा ॲथॉरिटेटिव्ह पत्ता बदलतो. प्रभावी आयुष्य संपेपर्यंत तो रिझॉल्व्हर जुना पत्ता परत पाठवणे सुरू ठेवू शकतो, जे लागू केलेल्या कोणत्याही किमान वेळेसाठी समायोजित केलेल्या रेकॉर्ड TTL आणि रिझॉल्व्हरच्या स्वतःच्या कमाल मर्यादेपेक्षा कमी असते. 24 तासांच्या रेकॉर्ड TTL आणि 6 तासांच्या कॅपसह, वापरकर्ते सहा तासांच्या आत नवीन पत्यावर पोहोचतात. 7 दिवसांच्या कॅप अंतर्गत 7 दिवसांच्या रेकॉर्ड TTL सह, ते पूर्ण एक आठवडा वाट पाहू शकतात.

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

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

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

रिझॉल्व्हरवरील फिल्टरिंग आणि सुरक्षा

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

कंटेंट फिल्टरिंग ॲक्सेसचे नियम सेट करते

श्रेणी-आधारित DNS फिल्टरिंग नेटवर्क मालकाला वापरकर्ते कोणत्या गंतव्यस्थानांपर्यंत पोहोचू शकतात हे ठरवू देते. एखादे कौटुंबिक पर्यटन स्थळ प्रशासकीय नेटवर्कसाठी वेगवेगळे नियम राखून अतिथी WiFi वर ॲडल्ट कन्टेंट प्रतिबंधित करू शकते.

डिव्हाइस साइट किंवा ॲप उघडण्यापूर्वी, ते ते कोठे शोधायचे हे DNS ला विचारते आणि डिव्हाइस ज्या नेटवर्कवर आहे त्या नेटवर्कच्या पॉलिसीचा वापर करून आम्ही उत्तर देतो. यामुळे केवळ विनंती केलेले डोमेनच नाही, तर नेटवर्कची ओळखही महत्त्वाची ठरते.

एखादी सेवा त्या प्रदान करत असली तरीही मुख्य कार्ये भिन्न असतात.

थ्रेट डिफेन्स गंतव्यस्थानाचे मूल्यमापन करते

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

ते एक उपयुक्त प्रतिबंध (containment) आहे, परंतु ते डिव्हाइसवरून मालवेअर काढून टाकत नाही. एंडपॉइंट संरक्षण आणि फायरवॉल नियंत्रणांची अद्याप स्वतःची कामे आहेत.

DNSSEC प्रमाणिकतेची तपासणी करते, सुरक्षेची नाही

DNSSEC व्हॅलिडेशन स्वाक्षरी केलेल्या DNS डेटाचे प्रमाणीकरण करण्यासाठी कॉन्फिगर केलेला ट्रस्ट अँकर आणि क्रिप्टोग्राफिक स्वाक्षऱ्यांची मालिका वापरते. RFC 4033 सुरक्षित व्हॅलिडेशनचे वर्णन करते आणि सांगते की, सुरक्षेबाबत जागरूक असलेल्या रिझॉल्व्हरने घड्याळाच्या चुकीच्या वेळेस अनुमती देऊन कॅशचे आयुष्य निवडताना स्वाक्षरीच्या वैधतेचा विचार केला पाहिजे.

त्यामुळे प्रशासकांना अचूक सिस्टीम वेळ आणि कॅश हँडलिंगची आवश्यकता असते जी व्हॅलिडेशन स्थिती जतन करते. रिझॉल्व्हरने कायदेशीररित्या अनसाइन केलेल्या डेटा आणि व्हॅलिडेशन अयशस्वी झालेल्या साइन केलेल्या डेटामधील फरक ओळखला पाहिजे.

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

योग्यरित्या साइन केलेले फिशिंग डोमेन हे तरीही फिशिंग डोमेनच असते. फिल्टरिंग हे ॲक्सेसला अनुमती द्यायची की नाही हे ठरवते; तर DNSSEC साइन केलेली DNS माहिती अस्सल आहे की नाही हे ठरवते.

आउटेज, जुनी उत्तरे आणि सामान्य गैरसमज

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

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

कॅश केलेली उत्तरे हे स्पष्ट करतात की ॲथॉरिटेटिव्ह आउटेज नेहमीच त्वरित ब्राउझिंग आउटेज का बनत नाही.

उपलब्धता आणि सुरक्षेसाठी स्पष्ट पर्याय आवश्यक असतात

Resolvers अयशस्वी परिणाम देखील कॅश करू शकतात. Negative caching नावाचे अस्तित्व नसणे यासारखी माहिती जतन करून ठेवते, ज्यामुळे त्याच गहाळ नावासाठी वारंवार होणारा शोध टळतो. अ‍ॅडमिनिस्ट्रेटरने ते नाव तयार केल्यानंतरही, काही क्लायंट्सना ते एक्सपायर होईपर्यंत कॅश केलेला नकारात्मक परिणामच मिळू शकतो.

विफलता हाताळणी एक वेगळा धोरणात्मक प्रश्न उपस्थित करते. फेअल-ओपन फिल्टरिंग डिझाइन जेव्हा सामान्य धोरण तपासण्या उपलब्ध नसतात तेव्हा त्यांच्याशिवाय रिझोल्यूशनची अनुमती देते. फेअल-क्लोज्ड डिझाइन ज्या विनंत्यांना मंजुरी देऊ शकत नाही त्यांना नकार देते, ज्यामुळे निर्बंध कायम राहतात परंतु कायदेशीर ॲक्सेसमध्ये व्यत्यय येऊ शकतो.

DNSSEC व्हॅलिडेशन अयशस्वी होणे हे आणखी एक वेगळे प्रकरण आहे. ऑपरेटरने केवळ पेज लोड ठेवण्यासाठी अमान्य स्वाक्षरी केलेला डेटा प्रमाणित मानू नये.

ऑपरेशनल चुकांना कारणीभूत ठरणारे गृहीतके

• रिकर्शनचा आपोआप अर्थ ब्लॉक करणे असा होतो: रिकर्शन उत्तरे मिळवते; प्रशासक पॉलिसी लेयरद्वारे ब्लॉक करण्याची सुविधा जोडतात.
• DNS फिल्टर प्रत्येक कनेक्शन नियंत्रित करतो: हार्ड-कोड केलेले डेस्टिनेशन ॲड्रेसेस आणि काही VPN पाथ्स सुरक्षित लुकअप पूर्णपणे टाळू शकतात.
• नेटवर्क DNS बदलल्याने प्रत्येक क्लायंट त्वरित हलतो: विद्यमान सेटिंग्ज, DHCP लीज आणि ब्राउझर-स्तरीय रिझॉल्व्हर पर्याय डिव्हाइसेसना दुसऱ्या पाथवर सोडू शकतात.

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

रिकर्शन उत्तरे हलवते. पॉलिसी आणि लवचिकता हे ठरवतात की बदलत्या परिस्थितींमध्ये नेटवर्क कोणती उत्तरे वितरीत करेल.

तुमचे नेटवर्क बदलण्यापूर्वी ते कोणता रिझॉल्व्हर वापरते याची पुष्टी करा

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

रोलआउट करण्यापूर्वी मार्ग तपासा

1. डिव्हाइसची कॉन्फिगर केलेली DNS सेवा शोधा. तिची नेटवर्क सेटिंग्ज किंवा DNS लुकअप टूल वापरा. राउटर पत्ता फॉरवर्डिंग सेवेचे प्रतिनिधित्व करू शकतो, म्हणून त्याच्या अपस्ट्रीम गंतव्याचा देखील मागोवा घ्या.
2. DHCP आणि कंट्रोलर सेटिंग्जची पाहणी करा. नेटवर्क कोणत्या रिसॉल्व्हरची जाहिरात करते आणि मॅन्युअली कॉन्फिगर केलेले क्लायंट त्याचे अनुसरण करतात की नाही याची पुष्टी करा.
3. आवश्यक पॉलिसी लिहून ठेवा. सामग्री श्रेणी, मालवेअर नियंत्रणे, लुकअप लॉगिंग आणि कर्मचार्‍यांच्या आणि अतिथींच्या ॲक्सेसमधील फरक ओळखा.
4. स्वीकार्य अपडेट वर्तन निवडा. सह्य रेकॉर्ड-रिफ्रेश आणि पॉलिसी-अपडेट विलंब, तसेच सेवा अयशस्वी झाल्यास अपेक्षित प्रतिसाद निर्दिष्ट करा.
5. मर्यादित नेटवर्कवर पायलट चालवा. बदल विस्तारित करण्यापूर्वी परवानगी असलेल्या साइट्स, ब्लॉक केलेली गंतव्यस्थाने, अंतर्गत संसाधने आणि रिकव्हरीची चाचणी घ्या.

डिप्लॉयमेंट ही कंट्रोलरवरील प्रति-नेटवर्क DNS सेटिंग किंवा DHCP बदल आहे, ज्यामध्ये क्लायंट डिव्हाइसेसवर काहीही इन्स्टॉल केले जात नाही. प्रत्येक ॲप्लिकेशन त्याचा वापर करतो याची गॅरंटी देण्याऐवजी, नेटवर्कच्या DNS कॉन्फिगरेशनचे अनुसरण करणाऱ्या डिव्हाइसेसचा यामध्ये समावेश होतो.

VPNs आणि DNS over HTTPS ची चाचणी करा, जे पर्यायी रिझोल्यूशन पाथ तयार करू शकतात. आमची टीम चाचणीपूर्वी नेटवर्क VPNs आणि एनक्रिप्टेड DNS कसे हाताळते हे दाखवते.

जेव्हा नेटवर्कला कनेक्शन सुरू होण्यापूर्वी फिल्टरिंगची आवश्यकता असते आणि मालक तिचे कॅश आणि फेल्युअर वर्तन स्वीकारतो, तेव्हा पॉलिसीसह रिकर्सिव्ह रिझॉल्व्हर हा योग्य पर्याय असतो.

---

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