एक द्वितीयक DNS सर्वर क्यों होना चाहिए?


26

मैं बड़ी उलझन में हूं।

मैं मूल रूप से समझता हूं कि DNS कैसे काम करता है। यहाँ एक उदाहरण है जो यह समझने में मदद करता है कि मुझे क्या समझने में परेशानी हो रही है।

अभी, मैं एक छोटा सा वेब-सर्वर चलाता हूं। मैं अपने प्रदाता के DNS प्रबंधक का उपयोग करता हूं, इसलिए मेरे पास मशीन पर होस्ट किया गया DNS सर्वर नहीं है।

चलो एक दूसरे के लिए कहते हैं, कि मैं अपने मेजबान के DNS का उपयोग नहीं करता हूं, और मैं अपने सर्वर पर एक DNS सर्वर स्थापित करने का निर्णय लेता हूं। Hypothetical परिदृश्य: मेरा सर्वर (संपूर्ण) सर्वर नीचे चला जाता है - DNS शामिल। मुझे बैकअप DNS की आवश्यकता क्यों है? यदि सर्वर डाउन है, तो DNS सर्वर डाउन होने पर भी कौन परवाह करता है, इस बात पर विचार करते हुए कि अगर मेरे पास DNS था (यह दुर्घटनाग्रस्त सर्वर पर नहीं था), तो यह वैसे भी अनुरोधों को अग्रेषित करने में सक्षम नहीं होगा क्योंकि सर्वर होगा नीचे?

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

उम्मीद है कि कोई देख सकता है कि मैं क्या कर रहा हूँ, और कुछ मार्गदर्शन प्रदान करता हूँ।


संभवतः प्रासंगिक: serverfault.com/q/710108/183318
Håkan लिंडक्विस्ट

जवाबों:


26

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

एक द्वितीयक DNS सर्वर हमेशा ऊपर है, और सेवा के लिए तैयार है। यह नेटवर्क पर लोड को संतुलित करने में मदद कर सकता है क्योंकि अब आपकी जानकारी प्राप्त करने के लिए एक से अधिक आधिकारिक स्थान हैं। अपडेट आमतौर पर मास्टर DNS से ​​स्वचालित रूप से किए जाते हैं। इस प्रकार यह गुरु का एक सटीक क्लोन है।

आम तौर पर एक DNS सर्वर में केवल एक सर्वर की तुलना में अधिक जानकारी होती है, इसमें मेल रूटिंग जानकारी, कई मेजबानों के लिए जानकारी, मेल स्पैम कुंजियाँ आदि हो सकती हैं, इसलिए लचीलापन और अतिरेक डोमेन धारकों के लिए DEFINITE लाभ के होते हैं।

मुझे उम्मीद है कि यह आपकी समझ में मदद करता है।


हालांकि आम तौर पर इन दिनों मेल सर्वर के साथ अगर एमएक्स रिकॉर्ड का समाधान नहीं होता है, तो संदेश को एकमुश्त खारिज करने के बजाय फिर से प्रयास करने के लिए एक कतार में डाल दिया जाता है - इसलिए यदि आप मेल सर्वर और / या एमएक्स डीएनएस रिकॉर्ड नीचे जाते हैं तो आपको इससे ठीक होना चाहिए एक मेल परिप्रेक्ष्य ... लेकिन फिर भी हर दूसरे तरीके से खराब!
विलियम

13

माध्यमिक DNS होने की बात है

केवल बेहद छोटे संगठन ही एक सर्वर पर सब कुछ कर सकते हैं। मेरे पास कई सर्वर हैं, मैं चाहता हूं कि मेरा ईमेल वेब सर्वर डाउन होने के बावजूद भी जारी रखने में सक्षम हो। मेरे पास बाहरी नेटवर्क पर होस्ट की जाने वाली सेवाएँ हैं, जो कि मेरे इंटरनेट लिंक डाउन होने पर भी मैं ऊपर रहना चाहता हूँ।

क्या एक बैकअप DNS सिस्टम मूल रूप से हर समय है?

आम तौर पर।

इसे कैसे कॉन्फ़िगर किया गया है?

यह डीएनएस सर्वर सॉफ्टवेयर पर निर्भर करता है, लेकिन आमतौर पर 'बैकअप सर्वर' पर, आप इसे द्वितीयक के रूप में सेट करते हैं। फिर आप मास्टर सर्वर के आईपी में बताते हैं, और जो आप चाहते हैं, वे क्षेत्र।


11

यह RFC का एक होना चाहिए। Http://www.ietf.org/rfc/rfc1035.txt देखें

पृष्ठ 4 से महत्वपूर्ण बातों का हवाला देने के लिए:

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


10

बैकअप DNS सर्वर (एक या अधिक) आपके प्राथमिक DNS सर्वर के दास होंगे। प्राथमिक DNS सर्वर में परिवर्तन दासों द्वारा उठाया जाएगा। यह आवधिक आधार पर, या प्राथमिक सर्वर से अधिसूचना के जवाब में हो सकता है। यह पूरे इंटरनेट में पहचाने जा रहे DNS में बदलावों में देरी का एक कारण है। आपके प्राथमिक और बैकअप नेमसर्वर को आपके डोमेन के लिए नेमसर्वर के रूप में सूचीबद्ध किया जाएगा।

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

बैकअप DNS सर्वर (नों) में कोई स्विचिंग नहीं है। DNS अनुरोधों को आपके सभी नेमसर्वरों में समान रूप से समान रूप से वितरित किया जाता है। (यह राउंड रॉबिन शेड्यूल का उपयोग करके सर्वरों को क्वेरी करके किया जाता है।) यदि एक या एक से अधिक नाम सर्वर नीचे हैं, तो टाइमआउट के बाद अनुरोधों को किसी अन्य नेमसेवर पर वापस ले लिया जाएगा। जब तक आपका एक नेमवेरर्स है, आपका डोमेन सुलझ जाएगा (धीरे-धीरे कई बार)। आप अपने सभी नेमसर्वर हमेशा चाहते हैं।

आपके मामले में, आप पा सकते हैं कि अपने डोमेन को होस्ट करने के लिए अपने आईएसपी या डोमेन रजिस्ट्रार का उपयोग करना सरल है। उनके पास एक या एक से अधिक बैकअप नेमसर्वर होंगे और उन्हें चालू रखने के लिए समर्पित संसाधन होंगे।


यदि आप सभी चला रहे हैं तो एक वेब सर्वर एक द्वितीयक DNS है जो महत्वपूर्ण नहीं लग सकता है। हालाँकि, जब आपका सर्वर डाउन होता है, तो कई कारण हो सकते हैं जिनमें आप एक बैकअप DNS सर्वर चाहते हैं, जिनमें शामिल हैं:

  • इसे नीचे सत्यापित करने के लिए आपको अपने मेजबान को पिंग या ट्रैसरआउट करने में सक्षम बनाने के लिए।
  • अपने डोमेन को तय करने से उपयोगकर्ताओं और क्रॉलर को रोकने के लिए अब उपयोग नहीं किया जाता है।

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


1

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

यदि आप अपने DNS को उन सेवाओं की मेजबानी करने वाले सर्वर से दूर होस्ट करते हैं जो 2 प्रदान करते हैं तो समझदार है। यदि एक नीचे जाता है तो दूसरा पिकअप कर लेगा और आपका डोमेन अभी भी उपलब्ध है।


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

1

उपरोक्त के अतिरिक्त:

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

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

नोट: सामान्य तौर पर अधिकतम का एक नकारात्मक-कैश अंतराल। 5 मिनट का सुझाव दिया गया है (फिर भी कुछ आईएसपी को वास्तव में पागल मान मिला)


1

आप सही हैं - आपको अपनी स्थिति में तीसरे पक्ष के द्वितीयक की आवश्यकता नहीं है, और यह आपको कुछ सुधार प्रदान करेगा, बशर्ते कि आपकी सभी अन्य सेवाएं (मेल सहित) अभी भी एक ही बॉक्स में एक ही होस्ट की जाती हैं नेटवर्क।

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

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

Djbdns के लेखक डीजेबी द्वारा एक द्वितीयक तृतीय-पक्ष DNS सेवा की गलत धारणाओं पर एक अच्छा अवलोकन प्रदान किया गया है:

http://cr.yp.to/djbdns/third-party.html

चलो पृष्ठ से एक सारांश उद्धरण है:

लब्बोलुआब यह है कि, अधिकांश साइटों के लिए, तृतीय-पक्ष DNS सेवा में तृतीय-पक्ष HTTP सेवा और तृतीय-पक्ष SMTP सेवा की तरह गंभीर लागत और नगण्य लाभ हैं। सेवा कंपनियों के दावे बेतहाशा अतिरंजित हैं, और उन्हें कभी भी सामान्य ज्ञान के विकल्प के रूप में उपयोग नहीं किया जाना चाहिए।


-6

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

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

कोशिश करो।


5
मैं वास्तव में नहीं जानता कि आप किस बारे में बात कर रहे हैं, आप वास्तव में यह नहीं समझते हैं कि DNS कैसे काम करता है। आपके क्लाइंट मशीन को कैशिंग DNS सर्वर पर इंगित किया जाना चाहिए, न कि एक सर्वर जो ज़ोन के लिए आधिकारिक है। यदि मैं प्राथमिक डिफ़ॉल्ट डिफॉल्ट के साथ उपलब्ध नहीं हूं, तो प्रत्येक सामान्य डीएनएस सर्वर सर्वर मैं अन्य नाम सर्वरों तक पहुंचने का प्रयास करूंगा। यदि DNS सर्वरों में से एक अनुचित तरीके से कॉन्फ़िगर किया गया है तो यह विफल नहीं हो सकता है।
Zoredache
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.