DNS i Nebula-fyren: vem får fråga om vilka poster?

Fyrrollen i Nebula gör mycket arbete som folk antar är automatiskt, och att svara på DNS är inte en av dem. Namntjänst är en valfri lyssnare som startar avstängd, och därför kan en värd som löser namn bra i overlayet sakna allt för att lösa en kollegas bärbara dator. Innan du slår på den måste du bestämma vem som ska kunna nå den och vilka posttyper du är villig att svara på, eftersom de två svaren skiljer sig.

Lyssnaren är valfri och avstängd som standard

Upptäckt och DNS är separata tjänster. Fyren hjälper peerar att hitta varandra och kan dessutom svara på namnsökningar om värdar den känner till, men den andra delen måste slås på uttryckligen i konfigurationen.

Bestäm vilka gränssnitt och nätverk som ska nå lyssnaren innan du aktiverar något. En DNS-tjänst som svarar på ett gränssnitt du inte avsåg blir ett litet informationsläckage utan en enda loggpost som någon läser. Beslutet är mycket billigare nu än att snäva in det senare, när något redan beror på det felaktiga svaret. Två rader konfiguration är lättare att motivera än en incidentanteckning om ett halvår.

A-poster och TXT delar inte publik

De två posttyperna besvaras under olika villkor, och att behandla dem som en enda tjänst är felet som den här artikeln finns för att förhindra.

Den asymmetrin är avsiktlig och inte en försummelse. En namn-till-adress-koppling är lite värd för en utomstående, medan certifikatmetadata beskriver identiteterna i ditt overlay. Flytta inte en förutsättning från den ena raden till den andra bara för att samma process svarar på båda.

Den svarar bara om fyrens egna värdar

Detta är inte en allmän resolver för ditt kontor, ditt moln-VPC eller det publika internet. Fyren svarar utifrån värdinformation som den har fått, och därför bor funktionen på fyrnoder i stället för på varje peer.

När ett namn misslyckas och overlayet inte har något med det att göra, hitta zonen och resolvern som faktiskt äger det. Att blanda in en overlay-resolver i en vårds allmänna DNS-konfiguration ger fel som ser slumpmässiga ut, eftersom vissa namn löses och andra besvaras av ingenting.

Håll också ett öga på bootstrap-ingångspunkten. Ett värdnamn som används för att nå den första fyren måste lösas via en vanlig väg innan upptäckten kan bero på det, så ett hönan-och-ägget-problem här ser exakt ut som ett trasigt overlay. Det rapporterar till och med på samma sätt: en peer som aldrig kommer upp och ingen uppenbar anledning. Kontrollera namnlösningen innan du rör certifikat, eftersom den ordningen fångar folk som började med den svårare halvan.

Kontrollera bindadressen och testa sedan utifrån

lighthouse.dns.host och lighthouse.dns.port avgör var den valfria tjänsten lyssnar. Gå igenom de värdena tillsammans med värdens brandvägg och nätverkspolicyn, eftersom en bindadress är en avsiktsförklaring och inte en säkerhetskontroll i sig.

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

Fråga från de nätverk du vill tillåta, inte från fyren själv. En lyckad sökning på fyren bevisar att processen kör och säger dig ingenting om vad en extern värd kan fråga om, och det är frågan som verkligen spelar roll.

Exponera den med avsikt

Namn och certifikatmetadata är användbar driftinformation, och nytta skär åt båda håll. Bestäm om lyssnaren bara ska vara för overlayet, vilka posttyper som tillåts och vem som granskar konfigurationen när den ändras.

Skriv sedan ner det bredvid fyrinställningarna. Nästa person som felsöker ett lösningsfel kommer annars att anta att tjänsten alltid funnits där. Hen kommer också att anta att den alltid var nåbar från var som helst hen råkar testa. Ett stycke som noterar bindadressen, de tillåtna näten och posttyperna sparar den personen en eftermiddag och sparar dig ett meddelande som frågar varför något ändrades.