क्या इंजीनियरिंग का अपना DNS ज़ोन, डेलीगेट या सबडोमेन होना चाहिए?

Question

हमारे पास हमारे संगठन का प्राथमिक डोमेन (AD के साथ) example.com है। अतीत में, पिछले प्रवेशों ने कई अन्य क्षेत्र बनाए हैं - जैसे dmn.com, lab.example.com, dmn-geo.com आदि - और साथ ही उप-डोमेन और प्रतिनिधि जो सभी विभिन्न इंजीनियरिंग समूहों के लिए हैं। अभी हमारा DNS थोड़ा गड़बड़ है। और निश्चित रूप से यह समस्याओं का कारण बनता है जब example.com में किसी कार्य केंद्र में किसी को इन अन्य क्षेत्रों / उप-क्षेत्रों में किसी सिस्टम से कनेक्ट करने की आवश्यकता होती है, या इसके विपरीत (आंशिक रूप से क्योंकि ज़ोन स्थानांतरण और प्रतिनिधिमंडल उनमें से अधिकांश के लिए ठीक से कॉन्फ़िगर नहीं किए जाते हैं) ।

हमारे उत्पादन DNS को सक्रिय निर्देशिका के साथ एकीकृत किया गया है, लेकिन इंजीनियरिंग सिस्टम को AD से अलग किया जाना चाहिए।

हम DNS के पुनर्गठन और इन सभी विभिन्न प्रविष्टियों को समेकित करने के तरीकों पर चर्चा कर रहे हैं। मुझे तीन अलग-अलग रास्ते दिखाई दे रहे हैं:

• एक नया क्षेत्र बनाएं अर्थात 'dmn.eng'। यह या तो आईटी द्वारा प्रबंधित किया जा सकता है, हमारे DNS सर्वर या इंजीनियरिंग का उपयोग करके उनके नेमसर्वर का उपयोग कर सकता है।
• एक नया प्रतिनिधि बनाएँ eng.example.com, उस उप-डोमेन में इंजीनियरिंग DNS को समेकित करें, और इंजीनियरों को प्रतिनिधि के लिए नेमसर्वर का प्रबंधन करने दें।
• बिना किसी प्रतिनिधिमंडल के साथ एक नया उपडोमेन eng.example.com बनाएं और स्वयं उपडोमेन के लिए DNS प्रबंधित करें।

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

यदि हम उपडोमेन को नहीं सौंपते हैं, तो इसका मतलब है कि गैर-उत्पादन डीएनएस को संभालने वाले उत्पादन के लिए बहुत अधिक काम (जो हम अनिवार्य रूप से पहले से ही कर रहे हैं)। फायदा यह है कि हम सभी डीएनएस पर पूरा नियंत्रण रखते हैं और जब कुछ काम नहीं करता है, तो इसे ठीक करने के लिए किसकी जिम्मेदारी है, इसमें कोई संदेह नहीं है। इंजीनियरिंग को और अधिक लचीलापन और नियंत्रण के लिए जरूरत पड़ने पर नियंत्रण देने के लिए हम geo.eng.example.com जैसे प्रतिनिधियों को भी जोड़ सकते हैं।

मैं वास्तव में एक नया क्षेत्र बनाने की आवश्यकता या लाभ के बारे में अनिश्चित हूं, dmn.eng।

तो इस तरह की स्थितियों के लिए उद्योग सर्वोत्तम अभ्यास और सिफारिशें क्या हैं? इंजीनियरिंग और उत्पादन के बीच निर्बाध नाम समाधान को लागू करने और प्रदान करने के लिए कौन सा समाधान सबसे सरल होगा? प्रत्येक समाधान के लिए कुछ संभावित लाभ या नुकसान हैं जो मुझे याद आ रहे हैं?

---

थोड़ी और जानकारी जोड़ने के लिए, हम एक काफी बड़ी निर्माण कंपनी हैं। ये इंजीनियर R & D, डेवलपमेंट और QA में काम करते हैं। लैब्स में अक्सर अपने स्वयं के सबनेट या पूरे नेटवर्क, डीएचसीपी, आदि होते हैं। संगठन और प्रौद्योगिकी के संबंध में, वे अपनी छोटी दुनिया की तरह हैं।

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

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

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

FYI करें, मैं केवल कुछ महीनों के लिए इस कंपनी में रहा हूं और पिछले AD / DNS व्यवस्थापक ने कंपनी छोड़ दी है, इसलिए मेरे पास इस संदर्भ के लिए कुछ भी नहीं है कि मौजूदा DNS संरचना में से कोई क्यों मौजूद है।

Comments

अधिक जानकारी के आधार पर अपडेट किया गया उत्तर।

— एमडीमोहोर313

Our production DNS is integrated with Active Directory, but engineering systems should be isolated from AD.यह टिप्पणी मुझे आश्चर्यचकित करती है यदि हो सकता है कि आपको इंजीनियरिंग के लिए एक अलग एडी वन होने पर ईमानदारी से विचार करना चाहिए।

— होपलेस

@ HoplessN00b वह चीज थी जिसकी हमने चर्चा की है। मैं उससे बचना चाहता हूं, क्योंकि यह सवाल को चौंका देता है "कौन इसे प्रबंधित करता है?" और निश्चित रूप से इंजीनियरिंग सभी नियंत्रण और लचीलापन चाहता है, लेकिन जिम्मेदारी में से कोई भी - "हमें इसे तब तक प्रबंधित करने दें जब तक यह टूट न जाए, तब आप इसे ठीक करें।"

— थॉमस

Answer 1

आज की दुनिया में, मैं मनमाने ढंग से शीर्ष स्तर के डोमेन के साथ नए ज़ोन बनाने की सलाह नहीं देता , क्योंकि ये इसे किसी भी समय "आधिकारिक डीएनएस" बना सकते हैं।

मैं व्यक्तिगत रूप से उपडोमेन डेलिगेशन परिदृश्य का पक्ष लूंगा, क्योंकि ऐसा लगता है कि आप क्या करने की कोशिश कर रहे हैं। (समेकित करें लेकिन इंजीनियरिंग को नियंत्रण दें)

शायद आप MS DNS के लिए एक वेब-फ्रंट-एंड भी पा सकते हैं, जहाँ इंजीनियरिंग रिकॉर्ड जोड़ / हटा सकती है, ताकि सर्वर अभी भी उत्पादन IT के स्वामित्व में है, और केवल एक चीज "वे" का प्रबंधन DNS प्रविष्टियाँ हैं।

Answer 2

सबसे पहले, सुनिश्चित करें कि आप कर ही domain.tld आप उपयोग करने की योजना (mit.edu)। यहां तक ​​कि अगर यह कभी इंटरनेट से कनेक्ट नहीं होता है, तो यह बात नहीं है।

Dn के पदानुक्रम होने के भारी लाभ हैं जो कम से कम कुछ हद तक org से मेल खाते हैं। मैंने इसे केवल तभी देखा है जब आईटी समर्थन के मामले में उस विभाग का प्रबंधन करने के लिए कोई व्यक्ति / लोग हैं। यह विज्ञापन के प्रयोजनों के लिए अलग-अलग क्षेत्र होने के संबंध में है। वेब पते और आदि एक अलग विषय हैं और यह उस पर लागू नहीं होंगे। मुझे डीएनएस पदानुक्रम के लिए कोई कठिन और तेज़ नियम नहीं है या नहीं, मुझे विश्वास है कि आपके ओआरजी की ज़रूरतें तय होंगी। कुछ क्षेत्रों में एक उपडोमेन (eng.mit.edu) और कुछ (hr.mit.edu, उदाहरण के लिए) की आवश्यकता नहीं होगी। बेशक, स्थिरता के लिए केवल एक शीर्ष स्तर का डोमेन होना चाहिए ।

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

मैं प्रत्येक क्षेत्र का पुनर्मूल्यांकन करूंगा और निर्धारित करूंगा

1. यदि यह अभी भी प्रासंगिक है। क्या सर्वर या वर्कस्टेशन अभी भी उस क्षेत्र में कुछ भी इंगित कर रहे हैं?

2. नए जोन का प्रबंधन कौन करेगा। यह कहे बिना जाता है कि ज़ोन को आपके नए पदानुक्रम में माइग्रेट करना होगा, लेकिन क्या आप ज़ोन के लिए फॉरवर्डिंग एड्रेस / नेमसेवर जानकारी को लागू करते हैं, या आप सक्रिय रूप से ज़ोन का प्रबंधन करेंगे ?

AD से कौन-सी प्रणालियाँ 'पृथक' हैं? क्या इनको नेटवर्क प्रमाणीकरण और / या प्रबंधन की आवश्यकता नहीं होगी? उन्हें DNS परिप्रेक्ष्य से अलग करने का क्या कारण है? अपने संदेह की पुष्टि करने के लिए, यह सब प्रबंधन में आसानी के बारे में है। अगर इंजीनियरिंग को प्रशासन की बहुत जरूरत है , तो उन्हें खुद को DNS प्रशासन मिलना चाहिए।

आपके अपडेट के आधार पर जानकारी जोड़ने के लिए, फिर मैं व्यक्तिगत रूप से उन्हें अपना उपडोमेन eng.spacelysprockets.com, और सबनेट भी दूंगा । इसे बाकी नेटवर्क से फायरवॉल किया जाना चाहिए, जिसमें उपयुक्त यातायात की अनुमति हो। यदि वे जाना चाहते हैं और बनाना चाहते हैं eng.eng.localया eng.bikesआप उन्हें रोक नहीं सकते हैं, और न ही आपको उस समर्थन का समर्थन करने के लिए मजबूर किया जाना चाहिए।

यदि वे अच्छा खेल लेते हैं तो सबज़ोन का उपयोग करें और तय करें कि वे तोड़ना चाहते हैं lab.eng.spacelysprockets.comऔर सबनेट का एक हिस्सा, उन पर है। यह शायद पेशेवर शिष्टाचार होना चाहिए ताकि आपको पता चल सके कि आप उस ट्रैफ़िक को भी सेगमेंट कर सकते हैं, लेकिन हर कोई ऐसा नहीं सोचता।

आपके बुनियादी ढांचे के लिए एक वास्तविक डोमेन नाम आपको प्रबंधन पर गंभीरता से लाभ देगा, आपको इस पर विचार करना चाहिए।

* यदि आप चाहिए और होगा आप दो अलग बातें हैं, लेकिन मैं पीछे हटना।