VPN पर NXDOMAIN का अर्थ टनल बंद होना नहीं है

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

उत्तर वास्तव में क्या सिद्ध करता है

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

यही अंतर तय करता है कि मरम्मत कहाँ होनी चाहिए। A रिकॉर्ड वाले होस्ट पर AAAA रिकॉर्ड का न होना होस्ट का न होना नहीं है, और उसके पीछे प्रमाणपत्र दोबारा जारी करना या टनल फिर से बनाना उपलब्ध एकमात्र सुराग़ बर्बाद करता है। यह भेद आगे के कदम का स्वरूप भी तय करता है: नामकरण की समस्या ज़ोन में ठीक होती है, और प्रकार की समस्या सही रिकॉर्ड माँगकर या यह स्वीकार करके ठीक होती है कि पता परिवार बस अनुपस्थित है।

भ्रम: निजी नाम का न होना टनल की विफलता है

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

split-horizon व्यवस्थाएँ इसे सामान्य बनाती हैं: वही ज़ोन नाम सार्वजनिक और आंतरिक रूप से अलग सामग्री के साथ मौजूद रहता है, और निजी रिकॉर्ड केवल आंतरिक रिज़ॉल्वर जानता है। इसलिए प्रामाणिक दिखने वाला नकारात्मक उत्तर मिलना इस बात का प्रमाण है कि किस रिज़ॉल्वर ने उत्तर दिया, इंटरफ़ेस की स्थिति का प्रमाण नहीं।

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

सही नाम के साथ सही रिज़ॉल्वर से पूछें

निर्णय दर्ज करने से पहले उत्तरदाता दर्ज करें। जो लुकअप यह नहीं दिखाता कि किस सर्वर ने उत्तर दिया, वह नीति की समस्या और नाम स्थान की समस्या में भेद नहीं कर सकता, और दोनों के सुधार असंबंधित हैं।

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

नकारात्मक कैशिंग सुधार के बाद की देरी समझाती है

नकारात्मक उत्तर डिज़ाइन के अनुसार कैश होते हैं, और RFC 2308 बताता है कि नकारात्मक कैश का जीवनकाल ज़ोन के प्राधिकार रिकॉर्ड से कैसे निकाला जाता है। इसलिए रिकॉर्ड या रिज़ॉल्वर नियम सुधारने से क्लाइंट पर तुरंत बदलाव की गारंटी नहीं मिलती, और जो लुकअप कैश किया गया उत्तर लौटाता रहता है उसे दोहराने से कुछ नया सिद्ध नहीं होता। केवल अलग उत्तरदाता, अलग नाम या खाली किया गया कैश ताज़ा प्रमाण देता है।

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

नाम को मार्ग से अलग करें

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

ट्रांसक्रिप्ट रखें: क्वेरी, उत्तरदाता, कोड और रिज़ॉल्व किया गया पता। यही रिकॉर्ड बाद की रिपोर्ट को सत्यापन-योग्य बनाता है, और यही निदान तथा धीमी लगने वाली टनल की कहानी का अंतर है।