अतिरेक और विलंबता में कमी के लिए DNS प्राइमरी / सेकेंडरी / सेट करने का सही तरीका?

Question

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

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

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

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

हमारे तर्कवादियों के तर्क में छेद करने के लिए मैं किन दलीलों का उपयोग कर सकता हूं? किसी भी ऑनलाइन संसाधन मैं उन समस्याओं को बेहतर ढंग से समझने के लिए परामर्श कर सकता हूं जो वे दावा करते हैं कि मौजूद हैं?

उत्तर पढ़ने के बाद कुछ अतिरिक्त नोट्स:

• हम लिनक्स पर हैं
• हमारे पास अतिरिक्त जटिल DNS आवश्यकताएं हैं; हमारी DNS प्रविष्टियाँ कुछ कस्टम सॉफ़्टवेयर द्वारा प्रबंधित की जाती हैं, जिसमें BIND वर्तमान में एक मुड़ DNS कार्यान्वयन से स्लाव कर रहा है, और साथ ही मिश्रण में कुछ दृश्य भी। हालाँकि हम दूसरे डेटा सेंटर पर अपने स्वयं के DNS सर्वर स्थापित करने में पूरी तरह से सक्षम हैं।
• मैं बाहरी सर्वरों के लिए आधिकारिक DNS के बारे में बात कर रहा हूं, हमारे स्थानीय ग्राहकों के लिए पुनरावर्ती DNS सर्वरों को नहीं।

Answer 1

वास्तव में बहुत बढ़िया है, यद्यपि काफी तकनीकी "बेस्ट प्रैक्टिसेस" दस्तावेज़ है जो आपके sysadmin का मुकाबला करते समय उपयोगी साबित हो सकता है। http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

यदि वह सिस्को द्वारा लिखे गए लेखों की वैधता को मान्यता नहीं देता है, तो हो सकता है कि आप सिसडमिन के साथ बहस करना बंद कर दें - प्रबंधन का एक स्तर ऊपर जाएं।

कई अन्य "बेस्ट प्रैक्टिस" दस्तावेज़ आपके प्राथमिक और द्वितीयक नेमसर्वरों को न केवल आईपी ब्लॉक से, बल्कि भौतिक स्थान से अलग करने की सलाह देते हैं। वास्तव में, RFC 2182 का मानना ​​है कि द्वितीयक DNS सेवाओं को भौगोलिक रूप से अलग किया जाता है। कई कंपनियों के लिए, इस का मतलब है एक और डेटासेंटर में एक सर्वर किराए पर, या इस तरह के रूप में एक की मेजबानी की DNS प्रदाता की सदस्यता ZoneEdit या UltraDNS ।

Answer 2

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

आह, फोकस भरोसेमंद है । ऐसा लगता है कि वे द्वितीयक DNS को स्थापित करने के बजाय, बाहर की तरफ आपके लिंक पर जाॅब ले रहे हैं। सभी समान हैं, द्वितीयक DNS सेट करते हैं और वहां से आगे बढ़ते हैं। यह लोड के साथ मदद करेगा और चीजों को चुटकी में आगे बढ़ाएगा ... लेकिन यह पूछें कि क्यों उन्हें लगता है कि अन्य स्थान भरोसेमंद नहीं है ।

व्यक्तिगत रूप से, मुझे विश्वास है कि हम इस तरह की समस्या वाली एकमात्र कंपनी नहीं हैं और यह सबसे अधिक संभावना है कि पहले से ही एक समस्या है। मैं उन सभी इंटरनेट कंपनियों की कल्पना नहीं कर सकता जो हमारी तरह की समस्या से प्रभावित हैं।

आप एकमात्र कंपनी नहीं हैं, और दुनिया भर की कंपनियों में यह संभवत: दस लाख बार हुआ है।

हालाँकि, मुझे अच्छे ऑनलाइन डॉक्स नहीं मिले हैं जो बताते हैं कि विफलता के मामलों में क्या होता है (उदाहरण के लिए, क्लाइंट टाइमआउट) और उनके आसपास कैसे काम करें।

हमारे तर्कवादियों के तर्क में छेद करने के लिए मैं किन दलीलों का उपयोग कर सकता हूं? किसी भी ऑनलाइन संसाधन मैं उन समस्याओं को बेहतर ढंग से समझने के लिए परामर्श कर सकता हूं जो वे दावा करते हैं कि मौजूद हैं?

• मैं बाहरी सर्वरों के लिए आधिकारिक DNS के बारे में बात कर रहा हूं, हमारे स्थानीय ग्राहकों के लिए पुनरावर्ती DNS सर्वरों को नहीं।

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

• आप अपनी डीएनएस सेवा को लोड के खामियाजे को संभालने के लिए प्राप्त करते हैं, अपने खुद के (आंतरिक) DNS की क्षमता के बारे में प्रश्नों को प्रस्तुत करते हैं।
• जब आप अपने इन-हाउस DNS सर्वर डाउन हो सकते हैं, तो रहने के लिए आपको अपनी DNS सेवा मिलती है, इसलिए इससे कोई फर्क नहीं पड़ता कि आपका लिंक कितना भरोसेमंद है - आपके DNS सेवा प्रदाता के लिए कितना विश्वसनीय है।

कारण कि यह गलत काम है:

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

Comments

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

— ग्रीबल्सनॉर्ट

टिप्पणी यह ​​है कि मैं इसे इस तरह क्यों करता हूं, +1 है। :) मैं थोड़ा iptables जादू के साथ उल्लेख करना भूल गया, आप केवल 53 सेकंड से बाहरी अनुरोधों के लिए पोर्ट 53 का जवाब दे सकते हैं, यह वास्तव में बहुत सुरक्षित बनाता है। फिर भी, यह पूरी तरह से "कोषेर" नहीं है और मुद्दों को पैदा कर सकता है। कुछ समय intodns.com के माध्यम से एक डोमेन चलाने की कोशिश करें और देखें कि यह क्या रिपोर्ट करता है ...

— एवरी पायने

Answer 3

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

यह अक्सर किसी भी अनुरोध के लिए 30s देरी तक का मतलब है। जब तक प्राथमिक नीचे है तब तक पहले माध्यमिक की कोशिश किए बिना।

मैं इसे हल करना चाहता था क्योंकि हमारे अमेज़ॅन ईसी 2 का नामकरण हल करने वाला हमारे कई श्रमिकों के लिए उपलब्ध नहीं है। यह हमारी प्रक्रियाओं में बड़ी देरी का कारण बनता है और कुछ मामलों में डाउनटाइम का भी क्योंकि हम संकल्प पर भरोसा करते हैं। मैं Google / Level3 नेमसर्वर के लिए एक अच्छी विफलता चाहता था यदि अमेज़ॅन फिर से नीचे चला गया। और ASAP वापस गिर जाते हैं, क्योंकि तब अमेज़ॅन होस्टनामों को स्थानीय पते पर लागू करेगा जहां लागू होता है, उदाहरण के लिए संचार के लिए कम विलंबता में हल करना।

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

मैंने crontab & bash का उपयोग करने का निर्णय लिया, और nsfailover.sh लिखा । उम्मीद है की यह मदद करेगा।

Comments

ddg के माध्यम से पायाlinux first dns server is down second works but is slow

— bgStack15

Answer 4

ऐसा लगता है कि समस्या यह है कि क्लाइंट कोई भी हो सकता है, कहीं भी- दो DNS सर्वर देखें और यदि कोई विफल रहता है, तो वे या तो द्वितीयक सर्वर को विफल नहीं करते हैं या वे करने से पहले एक लंबा समय समाप्त होता है।

मैं इस बात से सहमत हूं कि प्राथमिक और द्वितीयक DNS सर्वरों को सर्वोत्तम सुविधाओं के रूप में अलग-अलग सुविधाओं में स्थित होना चाहिए, लेकिन मैं यह नहीं देखता कि इस विशेष समस्या को कैसे ठीक किया जाएगा।

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

पता लगाने के लिए कुछ निर्देश एक लोड बैलेंसर होगा जो विभिन्न डेटा केंद्रों पर कई सर्वरों के लिए एकल आईपी पते के लिए ट्रैफ़िक पुनर्निर्देशित कर सकता है; या शायद किसी भी मार्ग अनुमार्गण।

Comments

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

— रयान

Answer 5

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

हमारा सेटअप है:

• 2 भौतिक डेटासेंटर (अलग सर्किट, आईएसपी और अपस्ट्रीम प्रदाता)
• प्रत्येक सुविधा में एक SLB के पीछे एक क्लस्टर में 2 भौतिक क्वेरी सर्वर
• 2 लोड संतुलन डिवाइस विशिष्ट रिकॉर्ड की सेवा करने के लिए जिसे हम दो डेटासेटर्स के बीच संतुलन का प्रबंधन करना चाहते हैं
• दोनों सर्वर क्लस्टर्स द्वारा आंतरिक रूप से सुलभ छिपे हुए मास्टर (मुझे सुरक्षा के लिए छिपे हुए मास्टर सेटअप में बहुत दृढ़ता से विश्वास है)

यह सेटअप पिछले 6 या 7 वर्षों में हमें लगभग 5 9 का अपटाइम देने के लिए पर्याप्त प्रभावी रहा है, यहां तक ​​कि अपडेट के लिए कभी-कभार सर्वर डाउनटाइम आदि के साथ, यदि आप कुछ अतिरिक्त डॉलर खर्च करने को तैयार हैं, तो आप आउटसोर्स पर देख सकते हैं। अल्ट्रोडन्स जैसे किसी के साथ ज़ोन की मेजबानी ...

KPWINC ने जो लोड वार्तालाप का उल्लेख किया है, वह 100% सही है। यदि आपका सबसे छोटा डेटासेंटर आपके लोड का 100% संभाल नहीं सकता है, तो आप वैसे भी संभावित रूप से बंधे हुए हैं क्योंकि आपका आउटेज तब होने वाला है जब आप कम से कम यह चाहते हैं =)

मैं अपने सभी एज राउटर से अधिकतम भार लेता हूं, उन सभी को एक साथ जोड़ता हूं, और फिर 0.65 से विभाजित करता हूं ... यही न्यूनतम बैंडविड्थ है जो हमारे पास प्रत्येक डेटासेंटर में होना चाहिए। मैंने लगभग 5 साल पहले उस नियम को लागू किया था, कुछ दस्तावेजों के साथ इसे सही ठहराने के लिए मैं सीसीओ से और इंटरनेट के बारे में इकट्ठा हुआ था, और इसने हमें कभी विफल नहीं किया। हालाँकि, आपको कम से कम तिमाही में उन आँकड़ों की जाँच करनी चाहिए । हमने पिछले साल नवंबर और फरवरी के बीच लगभग 3 गुना ट्रैफिक बढ़ाया था और मैं इसके लिए तैयार नहीं था। वह उज्ज्वल पक्ष यह है कि स्थिति ने मुझे कुछ बहुत स्पष्ट डेटा उत्पन्न करने की अनुमति दी है जो हमारे WAN सर्किट पर 72% लोड पर कहते हैं, हम पैकेट छोड़ना शुरू करते हैं। अधिक बैंडविड्थ के लिए मुझे कभी भी कोई अतिरिक्त औचित्य की आवश्यकता नहीं थी।

Answer 6

मुझे आपके विवरण को पढ़ने से एहसास हुआ कि यह स्पष्ट नहीं है कि क्या आप बाहरी सर्वर के लिए आधिकारिक DNS का मतलब अपने सर्वर को ढूंढना चाहते हैं, या अपने स्थानीय ग्राहकों के लिए पुनरावर्ती डीएनएस सर्वर को ढूंढना है। उन दोनों का व्यवहार बहुत अलग है।

आधिकारिक DNS सर्वरों के लिए, "क्लाइंट" अन्य DNS सर्वर होंगे जिनके पास कैशिंग और बहुत सारी बुद्धिमत्ता है। यदि वे पहले धीमी गति से हैं, तो वे एक साथ कई सर्वरों को आज़माएँगे, और उन्हें तेज़ी से उत्तर देने वाले को प्राथमिकता देना पसंद करेंगे। उस स्थिति में एक डेटा सेंटर के लिए डाउनटाइम का प्रदर्शन बहुत कम होता है।

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

यदि आपका प्राथमिक डेटासेंटर नीचे है, तो कोई भी उन सर्वरों तक किसी भी तरह से नहीं पहुंच पाएगा, लेकिन अक्सर इसमें से त्रुटियां अगम्य DNS सर्वरों की त्रुटियों की तुलना में अधिक समझदार होती हैं। "सर्वर से संपर्क नहीं कर सका" या "कनेक्शन का समय समाप्त हो गया" के बजाय "सर्वर नहीं मिल सका" या "ऐसा कोई सर्वर नहीं"। उदाहरण के लिए, अधिकांश SMTP सर्वर एक सप्ताह के लिए मेल को पंक्तिबद्ध करेंगे यदि वे DNS में सर्वर को देखते हैं, लेकिन अभी उस तक नहीं पहुंच सकते हैं; यदि वे इसे DNS में नहीं पा सकते हैं तो वे तुरंत इसे आपके डोमेन पर वितरित करने का प्रयास करने से मना कर सकते हैं।

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

Answer 7

थॉमस,

आपके अपडेट को पढ़ने के बाद मैंने अपनी पोस्ट को संशोधित किया है (पिछली पोस्ट में विंडोज़ सॉफ़्टवेयर का संदर्भ है)।

यह लगभग मुझे लगता है जैसे आपके sysadmin (s) आपको बता रहे हैं कि आपके द्वितीयक स्थान में FAD LOAD को संभालने के लिए आवश्यक हार्डवेयर नहीं है?

ऐसा लगता है जैसे वह कह रहा है, "अरे दोस्त, अगर हमारा प्राथमिक स्थान (जिसमें प्राथमिक DNS शामिल है) नीचे चला जाता है तो DNS हमारी चिंताओं का सबसे बड़ा कारण है क्योंकि अगर COLO1 नीचे है तो COLO2 वैसे भी लोड को संभाल नहीं सकता है।"

यदि यह मामला है, तो मैं आपको अपने बुनियादी ढांचे को देखने और बेहतर डिजाइन के साथ आने की कोशिश करने का सुझाव दूंगा। यह आसान काम की तुलना में कहा जाता है, खासकर अब जब आप एक उत्पादन वातावरण में रहते हैं।

एक तरफ एक परिपूर्ण दुनिया में, COLO1 और COLO2 अकेले खड़े होने और अपने भार को संभालने में सक्षम होंगे।

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

मैंने इस विधि का उपयोग छोटे से उचित आकार के वातावरण में किया है और यह बहुत अच्छा काम करता है। विफलता आमतौर पर 10 मिनट से कम समय लेती है।

आपको बस यह सुनिश्चित करना है कि आपके DNS सर्वर एक छोटी TTL (रहने का समय) के अतिरिक्त भार को संभाल सकते हैं।

उम्मीद है की यह मदद करेगा।

Comments

यह मेरे विचार का भी प्रकार था, लेकिन मैं यह जानना चाहता हूं कि वे इसे कैसे करते हैं :-)

— काइल ब्रान्ड

Answer 8

आपके sysadmins (ज्यादातर) गलत हैं।

आपके आधिकारिक सर्वर को क्वेरी करने वाले पुनरावर्ती सर्वर बहुत तेज़ी से नोटिस करेंगे यदि कोई भी साइट अप्रतिसादी है।

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

यदि आवश्यक हो (sysadmins को खुश करने के लिए) अपने प्राथमिक डेटा केंद्र पर दो सर्वर चलाना जारी रखें, लेकिन कम से कम एक और बाहर रखें।

Comments

क्या आपके पास इसके लिए कोई संदर्भ है?

— टेडी

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

— रयान

Answer 9

एक माध्यमिक डीएनएस सर्वर कभी भी दर्द नहीं करता है, जहां यह होस्ट किया गया है, इसके आधार पर यह आपको अधिक या कम कार्यक्षमता देगा।

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

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

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