DNS i Nebula-fyrtårnet: hvem kan spørre om hvilke oppføringer?

Fyrtårnrollen i Nebula gjør mye arbeid som folk antar er automatisk, og å svare på DNS er ikke en av dem. Navnetjeneste er en valgfri lytter som starter deaktivert, og derfor kan en vert som løser fint i overlayet ikke ha noe som helst å løse en kollegas bærbare med. Før du slår den på, må du bestemme hvem som skal kunne nå den, og hvilke oppføringstyper du er villig til å svare på, fordi de to svarene er forskjellige.

Lytteren er valgfri og av som standard

Oppdagelse og DNS er separate tjenester. Fyrtårnet hjelper peers med å finne hverandre og kan i tillegg svare på navnespørringer om verter det kjenner, men den andre delen må slås eksplisitt på i konfigurasjonen.

Bestem hvilke grensesnitt og nettverk som skal nå lytteren før du aktiverer noe. En DNS-tjeneste som svarer på et grensesnitt du ikke hadde tenkt på, blir en liten informasjonslekkasje uten en eneste loggoppføring som noen leser. Beslutningen er mye billigere nå enn å innsnevre senere, etter at noe avhenger av det feil svaret. To linjer konfigurasjon er lettere å begrunne enn et hendelsesnotat om et halvt år.

A-oppføringer og TXT deler ikke publikum

De to oppføringstypene besvares under ulike betingelser, og å behandle dem som én tjeneste er feilen denne artikkelen finnes for å hindre.

Den asymmetrien er bevisst og ikke en forglemmelse. En navn-til-adresse-kobling er lite verdt for en utenforstående, mens sertifikatmetadata beskriver identitetene i overlayet ditt. Ikke flytt en antakelse fra den ene raden til den andre bare fordi den samme prosessen svarer på begge.

Den svarer bare om fyrtårnets egne verter

Dette er ikke en generell resolver for kontoret ditt, sky-VPC-en eller det offentlige internettet. Fyrtårnet svarer fra vertsinformasjon det har fått, og derfor bor funksjonen på fyrtårnsnoder i stedet for på hver peer.

Når et navn feiler og overlayet ikke har noe med det å gjøre, finn sonen og resolveren som faktisk eier det. Å blande en overlay-resolver inn i en verts generelle DNS-konfigurasjon gir feil som ser tilfeldige ut, fordi noen navn løses og andre besvares av ingenting.

Følg også med på bootstrap-inngangspunktet. Et vertsnavn som brukes til å nå det første fyrtårnet, må løses via en vanlig vei før oppdagelsen kan avhenge av det, så et høne-og-egg-problem her ser nøyaktig ut som et ødelagt overlay. Det rapporterer til og med på samme måte: en peer som aldri kommer opp, og ingen åpenbar grunn. Sjekk navneløsning før du rører sertifikater, fordi den rekkefølgen fanger folk som begynte med den vanskeligste halvdelen.

Sjekk bind-adressen, og test deretter fra utsiden

lighthouse.dns.host og lighthouse.dns.port bestemmer hvor den valgfrie tjenesten lytter. Gå gjennom disse verdiene sammen med vertens brannmur og nettverkspolicyen, fordi en bind-adresse er en intensjonserklæring og ikke en sikkerhetskontroll i seg 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

Spør fra nettene du vil tillate, ikke fra fyrtårnet selv. Et vellykket oppslag på fyrtårnet beviser at prosessen kjører og sier deg ingenting om hva en ekstern vert kan spørre om, og det er spørsmålet som faktisk betyr noe.

Eksponer den med vilje

Navn og sertifikatmetadata er nyttig driftsinformasjon, og nytte skjærer begge veier. Bestem om lytteren bare skal være for overlayet, hvilke oppføringstyper som tillates, og hvem som går gjennom konfigurasjonen når den endres.

Skriv det så ned ved siden av fyrtårninnstillingene. Den neste personen som feilsøker en løsningsfeil vil ellers anta at tjenesten alltid har vært der. Vedkommende vil også anta at den alltid var tilgjengelig fra hvor som helst de tilfeldigvis tester. Ett avsnitt som noterer bind-adressen, de tillatte nettene og oppføringstypene sparer den personen en ettermiddag og sparer deg en melding som spør hvorfor noe ble endret.