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તમે મંજૂરી આપવા માંગતા નેટવર્કમાંથી પ્રશ્ન કરો, લાઇટહાઉસમાંથી જ નહીં. લાઇટહાઉસ પર સફળ શોધ સાબિત કરે છે કે પ્રક્રિયા ચાલી રહી છે અને બહારનું હોસ્ટ શું પૂછી શકે તે વિશે કંઈ કહેતું નથી, અને તે જ ખરેખર મહત્ત્વનો પ્રશ્ન છે.
તેને ઇરાદાપૂર્વક ખુલ્લું કરો
નામો અને સર્ટિફિકેટ મેટાડેટા ઉપયોગી ઓપરેશનલ માહિતી છે, અને ઉપયોગિતા બંને દિશામાં કપાય છે. નક્કી કરો કે શ્રોતા ફક્ત ઓવરલે માટે હોવો જોઈએ, કયા રેકોર્ડ પ્રકારોની મંજૂરી હોવી જોઈએ અને રૂપરેખાંકન બદલાય ત્યારે કોણ સમીક્ષા કરે છે.
પછી તેને લાઇટહાઉસ સેટિંગ્સની બાજુમાં લખો. રિઝોલ્યુશન નિષ્ફળતા ડિબગ કરનાર આગલી વ્યક્તિ અન્યથા ધારશે કે સેવા હંમેશા ત્યાં જ હતી. તે એ પણ ધારશે કે તે જ્યાં પણ પરીક્ષણ કરે છે ત્યાંથી હંમેશા પહોંચી શકાય તેવી હતી. બાઇન્ડ સરનામું, મંજૂર નેટવર્ક અને રેકોર્ડ પ્રકારો નોંધતો એક ફકરો તે વ્યક્તિનો એક બપોર બચાવે છે અને શા માટે કંઈક બદલાયું તે પૂછતો સંદેશ તમને બચાવે છે.