Nebula लाइटहाउस DNS: कौन कौन से रिकॉर्ड पूछ सकता है?
वैकल्पिक श्रोता लाइटहाउस के पास मौजूद होस्ट डेटा से उत्तर देता है। A रिकॉर्ड और TXT क्वेरी पहुँच और दर्शकों में भिन्न हैं, इसलिए इसे जानबूझकर बाँधें।
Nebula में लाइटहाउस की भूमिका बहुत काम करती है जिसे लोग स्वचालित मानते हैं, और DNS का उत्तर देना उनमें से एक नहीं है। नामों की सेवा एक वैकल्पिक श्रोता है जो बंद अवस्था में शुरू होता है, इसीलिए जो होस्ट ओवरले के भीतर नाम अच्छी तरह हल करता है, उसके पास साथी के लैपटॉप को हल करने के लिए कुछ भी नहीं हो सकता। इसे चालू करने से पहले तय करें कि किसे इसे पहुँचना चाहिए और किस प्रकार के रिकॉर्ड का उत्तर देने को आप तैयार हैं, क्योंकि ये दो उत्तर अलग हैं।
श्रोता वैकल्पिक है और डिफ़ॉल्ट रूप से बंद है
खोज और DNS अलग सेवाएँ हैं। लाइटहाउस साथियों को एक-दूसरे को खोजने में मदद करता है और इसके अतिरिक्त उन होस्टों के बारे में नाम-क्वेरी का उत्तर दे सकता है जिन्हें वह जानता है, लेकिन वह दूसरा भाग कॉन्फ़िगरेशन में स्पष्ट रूप से चालू करना पड़ता है।
कुछ भी सक्षम करने से पहले तय करें कि कौन-से इंटरफ़ेस और नेटवर्क श्रोता तक पहुँचने चाहिए। जो DNS सेवा ऐसे इंटरफ़ेस पर उत्तर देती है जिसका आपने इरादा नहीं किया था, वह बिना किसी लॉग प्रविष्टि के एक छोटा सूचना रिसाव बन जाती है जिसे कोई पढ़ता है। यह निर्णय अब लेना बाद में सीमित करने से कहीं सस्ता है, जब कोई चीज़ गलत उत्तर पर निर्भर हो जाए। दो पंक्तियों का कॉन्फ़िगरेशन छह महीने बाद की घटना-टिप्पणी से समझाना आसान है।
A रिकॉर्ड और TXT एक ही दर्शक वर्ग साझा नहीं करते
इन दो प्रकार के रिकॉर्ड का उत्तर अलग-अलग स्थितियों में दिया जाता है, और इन्हें एक ही सेवा मानना वही गलती है जिसे रोकने के लिए यह लेख है।
| Query | What it returns | Who can reach it |
|---|---|---|
| A record for a host name | That host Nebula IP | Any host that can reach the listener, overlay or not |
| TXT for a host IP | Certificate information | Only over the Nebula network |
यह असमानता जानबूझकर है, लापरवाही नहीं। बाहरी व्यक्ति के लिए नाम-से-पता मैपिंग का मूल्य कम है, जबकि प्रमाणपत्र मेटाडेटा आपके ओवरले की पहचानों का वर्णन करता है। केवल इसलिए कि एक ही प्रक्रिया दोनों का उत्तर देती है, एक पंक्ति से दूसरी में कोई अनुमान न ले जाएँ।
यह केवल लाइटहाउस के अपने होस्टों के बारे में उत्तर देता है
यह आपके दफ़्तर, क्लाउड VPC या सार्वजनिक इंटरनेट के लिए सामान्य रिज़ॉल्वर नहीं है। लाइटहाउस उसे दिए गए होस्ट जानकारी से उत्तर देता है, इसीलिए यह सुविधा हर साथी पर नहीं बल्कि लाइटहाउस नोड्स पर रहती है।
जब कोई नाम विफल हो जिसका ओवरले से कोई संबंध न हो, तो वह ज़ोन और रिज़ॉल्वर खोजें जो वास्तव में उसके स्वामी हैं। होस्ट के सामान्य DNS कॉन्फ़िगरेशन में ओवरले रिज़ॉल्वर मिलाने से ऐसी विफलताएँ बनती हैं जो बेतरतीब लगती हैं, क्योंकि कुछ नाम हल होते हैं और बाकी का कोई उत्तर नहीं देता।
इस पर भी ध्यान दें बूटस्ट्रैप प्रवेश बिंदु। पहले लाइटहाउस तक पहुँचने के लिए इस्तेमाल होने वाला होस्टनाम सामान्य मार्ग से हल होना चाहिए, इससे पहले कि खोज उस पर निर्भर कर सके, इसलिए यहाँ मुर्गी-और-अंडा की समस्या ठीक टूटे हुए ओवरले जैसी दिखती है। यह उसी तरह रिपोर्ट भी करता है: ऐसा साथी जो कभी ऊपर नहीं आता और कोई स्पष्ट कारण नहीं। प्रमाणपत्रों को छूने से पहले नाम हल होना जाँचें, क्योंकि यह क्रम उन लोगों को पकड़ता है जिन्होंने कठिन आधे से शुरुआत की।
बाइंड पता जाँचें, फिर बाहर से परखें
lighthouse.dns.host और lighthouse.dns.port तय करते हैं कि वैकल्पिक सेवा कहाँ सुनती है। इन मानों को होस्ट फ़ायरवॉल और नेटवर्क नीति के साथ समीक्षा करें, क्योंकि बाइंड पता आशय की घोषणा है और अपने आप में सुरक्षा नियंत्रण नहीं।
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortउन नेटवर्कों से क्वेरी करें जिन्हें आप अनुमति देना चाहते हैं, लाइटहाउस से ही नहीं। लाइटहाउस पर सफल खोज साबित करती है कि प्रक्रिया चल रही है और बाहरी होस्ट क्या पूछ सकता है इस बारे में कुछ नहीं बताती, और यही वह प्रश्न है जो वास्तव में मायने रखता है।
इसे जानबूझकर उजागर करें
नाम और प्रमाणपत्र मेटाडेटा उपयोगी परिचालन जानकारी हैं, और उपयोगिता दोनों ओर काटती है। तय करें कि श्रोता केवल ओवरले के लिए होना चाहिए या नहीं, किन रिकॉर्ड प्रकारों की अनुमति हो और कॉन्फ़िगरेशन बदलने पर कौन समीक्षा करता है।
फिर इसे लाइटहाउस सेटिंग्स के बगल में लिख दें। अगला व्यक्ति जो रिज़ॉल्यूशन विफलता डिबग करेगा, वरना मान लेगा कि सेवा हमेशा वहीं थी। वह यह भी मान लेगा कि यह जहाँ भी वह संयोग से परीक्षण कर रहा है वहाँ से हमेशा पहुँच में थी। बाइंड पता, अनुमत नेटवर्क और रिकॉर्ड प्रकार दर्ज करने वाला एक अनुच्छेद उस व्यक्ति का एक दोपहर बचाता है और आपको यह पूछने वाला संदेश बचाता है कि कोई चीज़ क्यों बदली।