Nebulas fyrtårns-DNS: hvem må forespørge hvilke poster?

Fyrtårnsrollen i Nebula udfører meget arbejde, som folk antager er automatisk, og at svare på DNS er ikke en af dem. Navnebetjening er en valgfri lytter, der starter deaktiveret, og derfor kan en vært, der opløser fint i overlayet, slet ikke have noget at opløse en kollegas bærbare med. Før du slår den til, skal du beslutte, hvem der skal kunne nå den, og hvilke posttyper du vil svare på, fordi de to svar er forskellige.

Lytteren er valgfri og slået fra som standard

Opdagelse og DNS er separate tjenester. Fyrtårnet hjælper peers med at finde hinanden og kan desuden svare på navneforespørgsler om værter, det kender, men den anden del skal slås eksplicit til i konfigurationen.

Beslut hvilke grænseflader og netværk der skal nå lytteren, før du aktiverer noget. En DNS-tjeneste, der svarer på en grænseflade, du ikke havde tænkt på, bliver et lille informationslæk uden nogen logpost, som nogen læser. Beslutningen er meget billigere nu end at indsnævre senere, efter noget afhænger af det forkerte svar. To linjer konfiguration er lettere at begrunde end et hændelsesnotat om seks måneder.

A-poster og TXT deler ikke publikum

De to posttyper besvares under forskellige betingelser, og at behandle dem som én tjeneste er den fejl, denne artikel findes for at forhindre.

Denne asymmetri er bevidst og ikke en forglemmelse. En navn-til-adresse-kobling er lidt værd for en udenforstående, mens certifikatmetadata beskriver identiteterne i dit overlay. Tag ikke en antagelse med fra den ene række til den anden, bare fordi den samme proces svarer på begge.

Den svarer kun om fyrtårnets egne værter

Dette er ikke en generel resolver til dit kontor, din cloud-VPC eller det offentlige internet. Fyrtårnet svarer ud fra værtsoplysninger, det har fået, og derfor bor funktionen på fyrtårnsnoder i stedet for på hver peer.

Når et navn fejler, og overlayet ikke har noget med det at gøre, så find den zone og resolver, der faktisk ejer det. At blande en overlay-resolver ind i en værts generelle DNS-konfiguration giver fejl, der ser tilfældige ud, fordi nogle navne opløses, og andre besvares af ingenting.

Hold også øje med bootstrap-endepunktet. Et værtsnavn, der bruges til at nå det første fyrtårn, skal opløses ad en almindelig vej, før opdagelsen kan afhænge af det, så et hønen-og-ægget-problem her ser præcis ud som et brudt overlay. Det rapporterer endda på samme måde: en peer, der aldrig kommer op, og ingen åbenlys grund. Tjek navneopløsning, før du rører certifikater, fordi den rækkefølge fanger folk, der begyndte med den svære halvdel.

Tjek bind-adressen, og test derefter udefra

lighthouse.dns.host og lighthouse.dns.port bestemmer, hvor den valgfrie tjeneste lytter. Gennemgå de værdier sammen med værtens firewall og netværkspolitikken, fordi en bind-adresse er en erklæring om hensigt og ikke en sikkerhedskontrol i sig selv.

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

Forespørg fra de netværk, du vil tillade, ikke fra fyrtårnet selv. Et vellykket opslag på fyrtårnet beviser, at processen kører, og fortæller dig intet om, hvad en udefrakommende vært kan spørge om, og det er det spørgsmål, der faktisk betyder noget.

Eksponer den med vilje

Navne og certifikatmetadata er nyttig driftsinformation, og nytte skærer begge veje. Beslut, om lytteren kun skal være for overlayet, hvilke posttyper der må tillades, og hvem der gennemgår konfigurationen, når den ændres.

Skriv det derefter ned ved siden af fyrtårnsindstillingerne. Den næste person, der fejlretter en opløsningsfejl, vil ellers antage, at tjenesten altid har været der. Vedkommende vil også antage, at den altid var tilgængelig fra hvor som helst, de tilfældigvis tester. Et afsnit, der noterer bind-adressen, de tilladte netværk og posttyperne, sparer den person en eftermiddag og sparer dig en besked, der spørger, hvorfor noget blev ændret.