DNS i Nebula-fyrtårnet: kven kan spørje om kva oppføringar?

Fyrtårnrolla i Nebula gjer mykje arbeid som folk trur er automatisk, og å svare på DNS er ikkje ein av dei. Namneteneste er ein valfri lyttar som startar deaktivert, og difor kan ein vert som løyser fint i overlayet ikkje ha noko som helst å løysa den berbare til ein kollega med. Før du slår han på, må du avgjere kven som skal kunne nå han, og kva oppføringstypar du er villig til å svare på, fordi dei to svara er ulike.

Lyttaren er valfri og av som standard

Oppdaging og DNS er skilde tenester. Fyrtårnet hjelper peerar med å finne kvarandre og kan i tillegg svare på namnespurnader om vertar det kjenner, men den andre delen må slåast eksplisitt på i konfigurasjonen.

Avgjer kva grensesnitt og nettverk som skal nå lyttaren før du aktiverer noko. Ei DNS-teneste som svarar på eit grensesnitt du ikkje hadde tenkt på, blir ein liten informasjonslekkasje utan ein einaste loggoppføring som nokon les. Avgjerda er mykje billegare no enn å snevre han inn seinare, etter at noko avheng av det gale svaret. To linjer konfigurasjon er lettare å grunngje enn eit hendingsnotat om eit halvt år.

A-oppføringar og TXT deler ikkje publikum

Dei to oppføringstypane blir svarte på under ulike vilkår, og å handsame dei som éi teneste er feilen denne artikkelen finst for å hindre.

Den asymmetrien er med vilje og ikkje ei gløymsle. Ei namne-til-adresse-kopling er lite verdt for ein utanforståande, medan sertifikatmetadata skildrar identitetane i overlayet ditt. Ikkje flytt ei føresetnad frå den eine rada til den andre berre fordi den same prosessen svarar på begge.

Han svarar berre om fyrtårnet sine eigne vertar

Dette er ikkje ein generell resolver for kontoret ditt, sky-VPC-en eller det opne internettet. Fyrtårnet svarar frå vertsinformasjon det har fått, og difor bur funksjonen på fyrtårnknutepunkt i staden for på kvar peer.

Når eit namn feilar og overlayet ikkje har noko med det å gjere, finn sona og resolveren som faktisk eig det. Å blande ein overlay-resolver inn i den generelle DNS-konfigurasjonen til ein vert gir feil som ser tilfeldige ut, fordi nokre namn blir løyste og andre blir svarte av ingenting.

Følg òg med på bootstrap-inngangspunktet. Eit vertsnamn som blir brukt til å nå det første fyrtårnet, må løysast via ein vanleg veg før oppdaginga kan avhenge av det, så eit høne-og-egg-problem her ser nøyaktig ut som eit øydelagd overlay. Det rapporterer til og med på same måte: ein peer som aldri kjem opp, og inga openberr grunn. Sjekk namneløysing før du rører sertifikat, fordi den rekkjefølgja fangar folk som byrja med den vanskelegaste halvdelen.

Sjekk bind-adressa, og test deretter frå utsida

lighthouse.dns.host og lighthouse.dns.port avgjer kvar den valfrie tenesta lyttar. Gå gjennom desse verdiane saman med brannmuren til verten og nettverkspolicyen, fordi ei bind-adresse er ei intensjonsfråsegn og ikkje ein tryggleikskontroll i seg sjølv.

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 frå netta du vil tillate, ikkje frå fyrtårnet sjølv. Eit vellukka oppslag på fyrtårnet beviser at prosessen køyrer og segjer deg ingenting om kva ein ekstern vert kan spørje om, og det er spørsmålet som faktisk tel.

Eksponer han med vilje

Namn og sertifikatmetadata er nyttig driftsinformasjon, og nytte skjer begge vegar. Avgjer om lyttaren berre skal vere for overlayet, kva oppføringstypar som er tillatne, og kven som går gjennom konfigurasjonen når han blir endra.

Skriv det så ned ved sida av fyrtårninnstillingane. Den neste personen som feilsøkjer ein løysingsfeil vil elles tru at tenesta alltid har vore der. Vedkomande vil òg tru at ho alltid var tilgjengeleg frå kvar som helst dei tilfeldigvis testar. Eitt avsnitt som noterer bind-adressa, dei tillatne netta og oppføringstypane sparer den personen ein ettermiddag og sparer deg ei melding som spør kvifor noko vart endra.