दो साइटें, एक निजी DNS ज़ोन: रिकॉर्ड किसके हैं?

आप हरी साइट पर एक होस्ट जोड़ते हैं, वह हरे उपयोगकर्ताओं के लिए हल होता है, और पीला दफ़्तर अब भी 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 उत्तर बताता है कि पीला रिज़ॉल्वर स्वयं को प्राधिकृत मानता है, द्वितीयक से पूछता है, या केवल अग्रेषित करता है। ये अलग-अलग विफलता विधियों वाले अलग डिज़ाइन हैं, और उत्तर आमतौर पर बताता है कि आपने वास्तव में कौन सा लागू किया।

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