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तपाईं अनुमति दिन चाहनुभएका नेटवर्कबाट क्वेरी गर्नुहोस्, लाइटहाउसबाटै होइन। लाइटहाउसमा सफल खोजले प्रक्रिया चलिरहेको प्रमाणित गर्छ र बाहिरी होस्टले के सोध्न सक्छ भन्नेबारे केही बताउँदैन, र वास्तवमा महत्त्वपूर्ण प्रश्न त्यही हो।
यसलाई जानाजान उद्घाटन गर्नुहोस्
नाम र प्रमाणपत्र मेटाडेटा उपयोगी सञ्चालन जानकारी हुन्, र उपयोगिता दुवैतर्फ काट्छ। श्रोता ओभरलेका लागि मात्र हुनुपर्छ कि, कुन रेकर्ड प्रकार अनुमति दिने र कन्फिगरेसन बदलिँदा कसले समीक्षा गर्छ भन्ने निर्णय गर्नुहोस्।
त्यसपछि यसलाई लाइटहाउस सेटिङको छेउमा लेख्नुहोस्। समाधान असफलता डिबग गर्ने अर्को व्यक्तिले अन्यथा सेवा सधैं त्यहीँ थियो भनी मान्नेछ। उसले सेवा आफू परीक्षण गर्ने जहाँबाट पनि सधैं पहुँचयोग्य थियो भनी पनि मान्नेछ। बाइन्ड ठेगाना, अनुमति दिइएका नेटवर्क र रेकर्ड प्रकार अभिलेख गर्ने एक अनुच्छेदले त्यो व्यक्तिको एक दिउँसो र केही किन बदलियो भनी सोध्ने सन्देश तपाईंको बचत गर्छ।