DNS në fanarin e Nebula: kush mund të pyesë cilat regjistrime?
Dëgjuesi opsional përgjigjet nga të dhënat e hosteve që mban fanari. Kërkesat për regjistrimet A dhe TXT ndryshojnë në arritshmëri dhe audiencë, prandaj lidhe me qëllim.
Roli i fanarit në Nebula bën shumë punë që njerëzit e mendojnë automatike, dhe përgjigjja për DNS nuk është një prej tyre. Shërbimi i emrave është një dëgjues opsional që niset i çaktivizuar, prandaj një host që zgjidh mirë brenda overlay mund të mos ketë fare me çfarë të zgjidhë laptopin e një kolegu. Përpara se ta ndizni, vendosni kush duhet ta arrijë dhe cilat lloje regjistrimesh jeni të gatshëm të përgjigjeni, sepse këto dy përgjigje ndryshojnë.
Dëgjuesi është opsional dhe i çaktivizuar si parazgjedhje
Zbulimi dhe DNS janë shërbime të veçanta. Fanari i ndihmon peer-ët të gjejnë njëri-tjetrin dhe përveç kësaj mund t'u përgjigjet kërkesave për emra rreth hosteve që njeh, por kjo pjesa e dytë duhet të aktivizohet në mënyrë të shprehur në konfigurim.
Vendosni cilat ndërfaqe dhe rrjete duhet ta arrijnë dëgjuesin përpara se të aktivizoni çdo gjë. Një shërbim DNS që përgjigjet në një ndërfaqe që nuk e kishit menduar bëhet një rrjedhje e vogël informacioni pa asnjë hyrje log që dikush lexon. Vendimi është shumë më i lirë tani sesa ta ngushtosh më vonë, kur diçka varet nga përgjigjja e gabuar. Dy rreshta konfigurimi justifikohen më lehtë sesa një shënim incidenti pas gjashtë muajsh.
Regjistrimet A dhe TXT nuk ndajnë të njëjtën audiencë
Këtyre dy llojeve të regjistrimeve u përgjigjemi në kushte të ndryshme, dhe trajtimi i tyre si një shërbim i vetëm është gabimi që ky artikull ekziston për të parandaluar.
| 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 |
Kjo asimetri është e qëllimshme dhe jo një lëshim. Hartëzimi i emrit në adresë ka pak vlerë për një të jashtëm, ndërsa të dhënat meta të certifikatës përshkruajnë identitetet në overlay-n tuaj. Mos e transportoni një supozim nga një rresht në tjetrin vetëm sepse i njëjti proces u përgjigjet të dyjave.
Përgjigjet vetëm për hostet e vetë fanarit
Ky nuk është një zgjidhës i përgjithshëm për zyrën tuaj, VPC-në në re ose internetin publik. Fanari përgjigjet nga informacioni i hosteve që i është dhënë, prandaj kjo veçori jeton në nyjet e fanarit dhe jo në çdo peer.
Kur një emër dështon dhe overlay nuk ka lidhje me të, gjeni zonën dhe zgjidhësin që vërtet e zotërojnë atë. Përzierja e një zgjidhësi overlay në konfigurimin e përgjithshëm DNS të një hosti prodhon dështime që duken të rastësishme, sepse disa emra zgjidhen dhe të tjerëve nuk u përgjigjet asgjë.
Vini re gjithashtu pikën e hyrjes bootstrap. Një emër hosti i përdorur për të arritur fanarin e parë duhet të zgjidhet përmes një rruge të zakonshme përpara se zbulimi të mund të mbështetet mbi të, prandaj problemi i pulës dhe vezës këtu duket saktësisht si një overlay i prishur. Madje raporton në të njëjtën mënyrë: një peer që nuk ngrihet kurrë dhe asnjë arsye e dukshme. Kontrolloni zgjidhjen e emrave përpara se të prekni certifikatat, sepse ky renditje kap njerëzit që filluan me gjysmën më të vështirë.
Kontrolloni adresën e lidhjes, pastaj provoni nga jashtë
lighthouse.dns.host dhe lighthouse.dns.port përcaktojnë ku dëgjon shërbimi opsional. Rishikoni ato vlera bashkë me firewall-in e hostit dhe politikën e rrjetit, sepse një adresë lidhjeje është deklaratë qëllimi dhe jo një kontroll sigurie në vetvete.
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortPyetni nga rrjetet që keni ndërmend të lejoni, jo nga vetë fanari. Një kërkim i suksesshëm në fanar provon se procesi po qarkullon dhe nuk ju thotë asgjë për atë që mund të pyesë një host i jashtëm, dhe kjo është pyetja që vërtet ka rëndësi.
Ekspozoje me qëllim
Emrat dhe të dhënat meta të certifikatës janë informacion operativ i dobishëm, dhe dobishmëria pret në të dyja drejtimet. Vendosni nëse dëgjuesi duhet të jetë vetëm për overlay, cilat lloje regjistrimesh lejohen dhe kush e rishikon konfigurimin kur ai ndryshon.
Pastaj shkruajeni pranë cilësimeve të fanarit. Personi tjetër që do të korrigjojë një dështim zgjidhjeje do të supozojë ndryshe se shërbimi ka qenë gjithmonë atje. Ai gjithashtu do të supozojë se ka qenë gjithmonë i arritshëm nga kudo që ai teston rastësisht. Një paragraf që regjistron adresën e lidhjes, rrjetet e lejuara dhe llojet e regjistrimeve i kursen atij personi një pasdite dhe ju kursen juve një mesazh që pyet pse ndryshoi diçka.