DNS svjetionika Nebula: ko može upitati koje zapise?

Uloga svjetionika u Nebuli obavlja mnogo posla za koji ljudi pretpostavljaju da je automatski, a odgovaranje na DNS nije jedan od njih. Posluživanje imena je neobavezni slušalac koji počinje isključen, zbog čega host koji se dobro razrješava unutar overlayja možda uopće nema čime razriješiti kolegin laptop. Prije nego ga uključite, odlučite ko treba da ga dosegne i koje tipove zapisa ste spremni da odgovarate, jer se ta dva odgovora razlikuju.

Slušalac je neobavezan i isključen po zadanom

Otkrivanje i DNS su odvojene usluge. Svjetionik pomaže peerovima da pronađu jedni druge i dodatno može odgovarati na upite imena o hostovima koje poznaje, ali taj drugi dio mora se izričito uključiti u konfiguraciji.

Odlučite koja mrežna sučelja i mreže treba da dosegnu slušalac prije nego što bilo šta omogućite. DNS usluga koja odgovara na sučelju koje niste namjeravali postaje malo curenje informacija bez zapisa u dnevniku koji iko čita. Odluku je sada mnogo jeftinije donijeti nego je kasnije sužavati, nakon što se nešto osloni na pogrešan odgovor. Dvije linije konfiguracije lakše je obrazložiti od bilješke o incidentu za šest mjeseci.

A zapisi i TXT ne dijele istu publiku

Na ta dva tipa zapisa odgovara se pod različitim uslovima, a tretiranje njih kao jedne usluge greška je koju ovaj članak postoji da spriječi.

Ta asimetrija je namjerna, a ne propust. Mapiranje imena na adresu ima malu vrijednost za autsajdera, dok metapodaci certifikata opisuju identitete u vašem overlayju. Ne prenosite pretpostavku s jednog reda na drugi samo zato što isti proces odgovara na oba.

Odgovara samo o vlastitim hostovima svjetionika

Ovo nije opšti resolver za vaš ured, vaš cloud VPC ili javni internet. Svjetionik odgovara iz podataka o hostovima koji su mu dati, zato i ta funkcija živi na čvorovima svjetionika, a ne na svakom peeru.

Kada ime ne uspije, a overlay nema s tim veze, pronađite zonu i resolver koji ga zaista posjeduju. Miješanje overlay resolvera u opštu DNS konfiguraciju hosta stvara otkaze koji izgledaju slučajno, jer neka imena se razrješavaju, a na druga ne odgovara ništa.

Pratite i bootstrap krajnju točku. Ime hosta koje se koristi za dosezanje prvog svjetionika mora se razriješiti običnim putem prije nego što se otkrivanje može osloniti na njega, pa problem kokoške i jajeta ovdje izgleda tačno kao pokvaren overlay. Čak se i prijavljuje na isti način: peer koji nikad ne ustaje i nikakav očigledan razlog. Provjerite razrješavanje imena prije nego što dirate certifikate, jer taj redoslijed hvata ljude koji su počeli s težom polovinom.

Provjerite adresu vezivanja, pa testirajte izvana

lighthouse.dns.host i lighthouse.dns.port određuju gdje neobavezna usluga sluša. Pregledajte te vrijednosti uz firewall hosta i mrežnu politiku, jer adresa vezivanja je izjava namjere, a ne sigurnosna kontrola sama po sebi.

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

Upućujte upite s mreža koje namjeravate dopustiti, ne sa samog svjetionika. Uspješno traženje na svjetioniku dokazuje da proces radi i ne govori vam ništa o tome šta vanjski host može pitati, a to je pitanje koje je zaista važno.

Izložite ga namjerno

Imena i metapodaci certifikata korisna su operativna informacija, a korisnost siječe na obje strane. Odlučite da li slušalac treba biti samo za overlay, koji tipovi zapisa se dopuštaju i ko pregleda konfiguraciju kada se promijeni.

Zatim to zapišite pored postavki svjetionika. Sljedeća osoba koja bude otklanjala kvar razrješavanja inače će pretpostaviti da je usluga oduvijek bila tu. Također će pretpostaviti da je oduvijek bila dostupna odakle god slučajno testira. Jedan odlomak koji bilježi adresu vezivanja, dopuštene mreže i tipove zapisa štedi toj osobi jedno poslijepodne i štedi vama poruku s pitanjem zašto se nešto promijenilo.