DNS in de Nebula-vuurtoren: wie mag welke records opvragen?
De optionele listener antwoordt uit hostgegevens die de vuurtoren heeft. A-records en TXT-query's verschillen in bereikbaarheid en publiek, dus bind hem bewust.
De vuurtorenrol in Nebula doet veel werk dat mensen automatisch achten, en DNS beantwoorden hoort daar niet bij. Naamsdienst is een optionele listener die uitgeschakeld start, waardoor een host die binnen de overlay goed resolveert helemaal niets heeft om de laptop van een collega te resolven. Voordat je hem aanzet, bepaal je wie hem moet kunnen bereiken en welke recordtypen je wilt beantwoorden, want die twee antwoorden verschillen.
De listener is optioneel en standaard uit
Ontdekking en DNS zijn aparte diensten. De vuurtoren helpt peers elkaar te vinden en kan daarnaast naamquery's beantwoorden over hosts die hij kent, maar dat tweede deel moet expliciet in de configuratie worden aangezet.
Bepaal welke interfaces en netwerken de listener moeten bereiken voordat je iets activeert. Een DNS-dienst die antwoordt op een interface die je niet bedoelde, wordt een klein informatielek zonder één logregel die iemand leest. De beslissing is nu veel goedkoper dan hem later te vernauwen, wanneer iets van het verkeerde antwoord afhangt. Twee regels configuratie zijn makkelijker te verantwoorden dan een incidentnotitie over een half jaar.
A-records en TXT delen geen publiek
Deze twee recordtypen worden onder verschillende voorwaarden beantwoord, en ze als één dienst behandelen is de fout die dit artikel wil voorkomen.
| Query | What it returns | Who can reach it |
|---|---|---|
| A record for a host name | That host Nebula IP | Any host that can reach the listener, overlay or not |
| TXT for a host IP | Certificate information | Only over the Nebula network |
Die asymmetrie is bewust en geen vergissing. Een naam-naar-adres-koppeling is voor een buitenstaander weinig waard, terwijl certificaatmetadata de identiteiten in je overlay beschrijft. Neem geen aanname mee van de ene regel naar de andere, alleen omdat hetzelfde proces beide beantwoordt.
Hij antwoordt alleen over de eigen hosts van de vuurtoren
Dit is geen algemene resolver voor je kantoor, je cloud-VPC of het openbare internet. De vuurtoren antwoordt uit hostinformatie die hij heeft gekregen, en daarom woont de functie op vuurtorenknooppunten en niet op elke peer.
Als een naam faalt die niets met de overlay te maken heeft, zoek dan de zone en de resolver die hem werkelijk bezitten. Een overlay-resolver door de algemene DNS-configuratie van een host mengen levert fouten op die willekeurig lijken, omdat sommige namen wel resolven en andere door niets worden beantwoord.
Let ook op het bootstrap-ingangspunt. Een hostnaam die wordt gebruikt om de eerste vuurtoren te bereiken, moet via een gewoon pad resolven voordat ontdekking erop kan vertrouwen, dus een kip-en-ei-probleem ziet er hier precies uit als een kapotte overlay. Het meldt zich zelfs op dezelfde manier: een peer die nooit opkomt en geen duidelijke reden. Controleer naamresolutie voordat je certificaten aanraakt, want die volgorde vangt mensen die met de moeilijkere helft begonnen.
Controleer het bindadres en test dan van buitenaf
lighthouse.dns.host en lighthouse.dns.port bepalen waar de optionele dienst luistert. Bekijk die waarden samen met de firewall van de host en het netwerkbeleid, want een bindadres is een intentieverklaring en niet op zichzelf een beveiligingsmaatregel.
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortVraag het vanuit de netwerken die je wilt toestaan, niet vanaf de vuurtoren zelf. Een geslaagde opzoeking op de vuurtoren bewijst dat het proces draait en zegt je niets over wat een externe host kan vragen, en dat is de vraag die er werkelijk toe doet.
Stel hem bewust beschikbaar
Namen en certificaatmetadata zijn nuttige operationele informatie, en nut snijdt twee kanten op. Bepaal of de listener alleen voor de overlay moet zijn, welke recordtypen toegestaan zijn en wie de configuratie beoordeelt wanneer die verandert.
Schrijf het dan op naast de vuurtoreninstellingen. De volgende persoon die een resolutiefout debugt, gaat er anders van uit dat de dienst er altijd al was. Die persoon gaat er ook van uit dat hij altijd bereikbaar was vanaf waar hij toevallig test. Eén alinea met het bindadres, de toegestane netwerken en de recordtypen bespaart die persoon een middag en bespaart jou een bericht met de vraag waarom iets is veranderd.