MagicDNS डिवाइस हल करता है लेकिन ऑफ़िस होस्टनाम क्यों नहीं

MagicDNS tailnet के हर डिवाइस को उसके मशीन नाम और tailnet के DNS डोमेन से बना नाम देता है। यह नाम Tailscale बनाता है और इसका उत्तर Tailscale के रिज़ॉल्वर पथ से दिया जाता है। files.office.example जैसा ऑफ़िस होस्टनाम ऐसे ज़ोन का है जिसे Tailscale ने कभी नहीं लिखा, इसलिए डिवाइस का नाम बदलने से वह नहीं बन सकता। दोनों नामस्थान साथ-साथ मौजूद हैं; बस उनके मालिक अलग हैं।

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

दो नामस्थान, दो मालिक

डिवाइस का नाम मशीन के अपने होस्टनाम से बनता है, टकराव Tailscale हल करता है, और परिणाम tailnet डोमेन के अंतर्गत रहता है। ऑफ़िस ज़ोन उसे बनाए रखता है जो ऑफ़िस रिज़ॉल्वर चलाता है, और रिकॉर्ड प्रशासक या गतिशील पंजीकरण से बनते हैं। छोटे नाम अंतर छिपाते हैं: files शायद ऑफ़िस DNS द्वारा उत्तरित खोज-प्रत्यय विस्तार हो, कोई tailnet डिवाइस, या कुछ भी नहीं। पूरे नाम की क्वेरी दिखाती है कि वास्तव में किस सिस्टम ने उत्तर दिया।

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

ऑफ़िस ज़ोन को उसके रिज़ॉल्वर की ओर ले जाएँ

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

सीमित नाम सर्वर को उससे जुड़े डोमेन के लिए आधिकारिक होना चाहिए, नहीं तो उत्तर पते के बजाय एक रेफ़रल होगा।

पहुँच हल होने से पहले आती है

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

यह अंतर नैदानिक है। समय-समाप्ति रूटिंग या नीति की ओर इशारा करती है, जबकि तत्काल नकारात्मक उत्तर रिकॉर्ड या ज़ोन की ओर। कोई भी DNS सेटिंग बदलने से पहले पढ़ें कि आपको कौन सा मिलता है।

नाम की विफलता को सेवा की विफलता से अलग करें

अगर संसाधन अपने निजी पते पर उत्तर देता है पर होस्टनाम से नहीं, तो जाँच DNS पर ही रहती है। अगर दोनों में से कोई काम नहीं करता, तो पहले रूटिंग या सेवा ठीक करें, क्योंकि ऐसे पते पर हल होने वाला नाम जहाँ पहुँचा न जा सके, प्रगति नहीं है। पूरे नाम की क्वेरी करें और नोट करें कि किस सर्वर ने उत्तर दिया। macOS पर कुछ कमांड-लाइन उपकरण सामान्य अनुप्रयोगों से अलग पथ लेते हैं, इसलिए एक टर्मिनल dig और एक ब्राउज़र एक ही नाम पर असहमत हो सकते हैं।

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

ज़ोन, रिज़ॉल्वर का पता और क्वेरी ले जाने वाला रूट लिख लें। ये तीन नाम बदलने के एक और दौर के बिना अधिकांश MagicDNS आश्चर्य समझाते हैं।