दुई साइट, एउटा निजी DNS जोन: रेकर्ड कसको हो?
अलग रेकर्ड सूची भएका साइटहरू VPN मार्फत प्रतिकृति हुँदैनन्। साझा अधिकार वा प्रत्यायोजित साइट उपडोमेन छान्नुहोस्, त्यसपछि प्रत्येक रिजोल्भरलाई त्यतातिर निर्देशित गर्नुहोस्।
तपाईं हरियो साइटमा एउटा होस्ट थप्नुहुन्छ, त्यो हरियो प्रयोगकर्ताहरूका लागि समाधान हुन्छ, र पहेंलो कार्यालयले अझै NXDOMAIN पाउँछ। यो VPN को असफलता होइन र बिग्रिएको रिजोल्भर पनि होइन; यो निजी जोनभित्रको स्वामित्वको खाली ठाउँ हो। अलग-अलग सम्पादित दुई रेकर्ड सूचीहरू साइटहरू एकअर्कासम्म पुग्न सक्ने भएकै कारण एउटै जोन हुँदैनन्। समाधान प्रकाशन योजना हो, अर्को फायरवाल नियम होइन।
लक्षणले हराइरहेको मालिकको नाम बताउँछ
प्रत्येक साइटमा कसैले नाम आवश्यक पर्दा थपेको स्थानीय ओभरराइड, Pi-hole प्रविष्टि वा dnsmasq लाइन हुन सक्छ। हरियो रेकर्ड हरियो रिजोल्भरमा मात्र हुन्छ, त्यसैले पहेंलोमा रहेको क्लाइन्टले आफ्नै रिजोल्भरलाई सोध्छ र सत्य "यस्तो नाम छैन" प्राप्त गर्छ। पुरानो जवाफ फरक देखिन्छ: होस्ट सर्यो, एउटा साइटले आफ्नो प्रतिलिपि अद्यावधिक गर्यो, र अर्कोले अझै पुरानो ठेगाना फर्काउँछ।
क्यास खाली गरेर कुनै पनि ढाँचा लामो समय सुधारिँदैन। फर्वार्डिङ रिजोल्भरको क्यास एक पटक प्राप्त गरेको जवाफको प्रतिलिपि हो, नयाँ नाम प्रकाशित गर्ने अधिकार होइन, त्यसैले आज काम गर्ने क्यासले भोलिको होस्टबारे केही भन्दैन। BIND को कागजातले प्राथमिक, द्वितीयक, पुनरावर्ती र फर्वार्डिङ भूमिकाहरूलाई ठ्याक्कै यही कारणले अलग-अलग वर्णन गर्छ।
त्यसैले डिजाइनको प्रश्न साँघुरो र जवाफ दिन सकिने छ: रेकर्ड कसले बनाउन सक्छ, र त्यो रेकर्डले यसको जवाफ दिनुपर्ने प्रत्येक रिजोल्भरसम्म कसरी पुग्छ?
विकल्प A: द्वितीयकसहित एउटा अधिकृत जोन
internal.example.com का लागि प्राथमिक चलाउनुहोस् र समर्थित द्वितीयकहरूलाई प्रत्येक साइटमा जोन लिन दिनुहोस्। प्रत्येक साइटको पुनरावर्ती रिजोल्भरले आफ्नो स्थानीय द्वितीयकलाई सोध्छ, त्यसैले जवाफहरू क्यासबाट नभई अधिकृत स्रोतबाट आउँछन्, र एक पटक गरिएको परिवर्तन फेरि टाइप गर्नुको सट्टा स्थानान्तरण हुन्छ।
यो व्यवस्थाका लागि स्पष्ट निर्णय आवश्यक छ जसलाई स्थगित गर्न सजिलो र छोड्न महँगो हुन्छ। जोन कसले सम्पादन गर्न सक्छ? कुन सर्भरहरूलाई यो स्थानान्तरण गर्न अनुमति छ, र कुन ठेगानाबाट? साइटहरूबीचको सुरुङ बन्द हुँदा क्लाइन्टहरूले के देख्नुपर्छ? द्वितीयकले आफ्नो अन्तिम प्रतिलिपिबाट जवाफ दिइरहन्छ, जुन सामान्यतया चाहिने व्यवहार हो, तर यो घोषित छनोट हुनुपर्छ, अवरोधको समयमा अचम्म होइन।
जोन स्थानान्तरणलाई ठेगानाअनुसार परिचित द्वितीयकमा सीमित राख्नुहोस् र कार्यान्वयनले समर्थन गर्ने ठाउँमा कारोबार हस्ताक्षर प्रयोग गर्नुहोस्। खुला स्थानान्तरण भनेको पोर्टसम्म पुग्न सक्ने जोकोहीका लागि तपाईंको आन्तरिक नामस्थानको प्रतिलिपि हो।
लागत समन्वय हो: एउटा सम्पादन मार्ग, एउटा परिवर्तन समीक्षा, र रेकर्ड गलत हुँदा को ड्युटीमा छ भन्ने साझा बुझाइ।
विकल्प B: प्रत्येक साइटका लागि उपडोमेन
हरियो साइटलाई green.internal.example.com र पहेंलो साइटलाई yellow.internal.example.com प्रत्यायोजित गर्नुहोस्। प्रत्येक साइट आफ्ना नामहरूका लागि अधिकृत हुन्छ, र मूल जोनले प्रत्यायोजन रेकर्ड मात्र बोक्छ। एउटा फाइलको प्रतिस्पर्धा हराउँछ, र स्थानीय टोलीले केन्द्रीय परिवर्तनको प्रतीक्षा नगरी होस्ट थप्न सक्छ।
प्रत्यायोजन मूल जोनमा हुनुपर्छ, साइटका अधिकृत सर्भरहरूतर्फ देखाउने NS रेकर्डसहित। पूर्ण प्रत्यायोजन अव्यावहारिक हुँदा उपडोमेनका लागि सशर्त फर्वार्ड मान्य विकल्प हो, तर त्यो रिजोल्भर सेटिङ हो, प्रकाशित तथ्य होइन, त्यसैले प्रत्येक रिजोल्भरलाई उही नियम चाहिन्छ।
लागत हराउनुको सट्टा सर्छ: मूल जोनलाई अझै मालिक चाहिन्छ, र नयाँ साइट बनाउनु अब एकको सट्टा दुई ठाउँमा परिवर्तन हो।
प्रत्येक रिजोल्भरले छनोट पछ्याओस्
समर्थित कन्फिगरेसनमार्फत क्लाइन्टहरूलाई स्वीकृत रिजोल्भर र खोज डोमेन दिनुहोस्, र सुनिश्चित गर्नुहोस् कि रिजोल्भरसँग सोध्नुपर्ने कुनै पनि टाढाको DNS सर्भरसम्म स्वीकृत VPN मार्ग छ. ती जवाफहरूले फर्काउने निजी ठेगानासम्म अनुप्रयोगहरूलाई पनि मार्ग चाहिन्छ, किनकि मार्ग नभएको सही नाम पनि टुटेको जडान हो।
यदि Pi-hole ले स्थानीय समाधान दिन्छ भने, कुन रेकर्ड यसको स्वामित्वमा छन् र कुन क्वेरी यसले फर्वार्ड गर्छ लेख्नुहोस्। अलग-अलग सम्पादित दुई Pi-hole सूचीहरू अझै प्रतिकृति हुँदैनन्। Pi-hole v6 मा अनुकूलित dnsmasq लाइनहरू TOML, CLI वा वातावरण चरजस्ता होस्ट-पक्ष विकल्पबाट सेट गरिन्छ र API मार्फत खुलासा गरिँदैन; /etc/dnsmasq.d/ फाइलहरू लोड गर्नु पूर्वनिर्धारित रूपमा बन्द रहेको छुट्टै विकल्प हो।
त्यसपछि सबैतिर देखिनुपर्ने नामसँग दुवैतर्फबाट परीक्षण गर्नुहोस्:
$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53
SOA जवाफले तपाईंलाई पहेंलो रिजोल्भरले आफूलाई अधिकृत मान्छ, द्वितीयकलाई सोध्छ, वा मात्र फर्वार्ड गर्छ भन्ने बताउँछ। यी फरक असफलता विधि भएका फरक डिजाइन हुन्, र जवाफले सामान्यतया तपाईंले वास्तवमा कुन तैनाथ गर्नुभयो पहिचान गर्छ।
तीन स्वीकृति अवस्थासँग अन्त्य गर्नुहोस्: प्रत्येक साइटबाट एउटा नाम, एक घण्टाभित्र परिवर्तन भएको एउटा रेकर्ड, र साइटहरूबीचको लिङ्क अनुपलब्ध। पहिलो मात्र पास गर्ने डिजाइनसँग कागजमा प्रकाशन योजना र उत्पादनमा स्थानीय ओभरराइड हुन्छ।