DNS im Nebula-Leuchtturm: Wer darf welche Einträge abfragen?
Der optionale Listener antwortet aus Hostdaten, die der Leuchtturm hält. A-Einträge und TXT-Abfragen unterscheiden sich in Erreichbarkeit und Publikum, also binde ihn bewusst.
Die Leuchtturm-Rolle in Nebula erledigt viel Arbeit, die Leute für automatisch halten, und DNS zu beantworten gehört nicht dazu. Namensdienst ist ein optionaler Listener, der deaktiviert startet, weshalb ein Host, der im Overlay gut auflöst, überhaupt nichts hat, um den Laptop einer Kollegin aufzulösen. Bevor du ihn einschaltest, entscheide, wer ihn erreichen soll und welche Eintragstypen du beantworten willst, denn diese beiden Antworten unterscheiden sich.
Der Listener ist optional und standardmäßig aus
Erkennung und DNS sind getrennte Dienste. Der Leuchtturm hilft Peers, einander zu finden, und kann zusätzlich Namensabfragen zu Hosts beantworten, die er kennt, aber dieser zweite Teil muss in der Konfiguration ausdrücklich eingeschaltet werden.
Entscheide vor dem Aktivieren, welche Schnittstellen und Netze den Listener erreichen sollen. Ein DNS-Dienst, der auf einer nicht beabsichtigten Schnittstelle antwortet, wird zu einem kleinen Informationsleck ohne Protokolleintrag, den jemand liest. Die Entscheidung ist jetzt viel billiger als später einzuschränken, wenn etwas von der falschen Antwort abhängt. Zwei Zeilen Konfiguration sind leichter zu begründen als eine Incident-Notiz in einem halben Jahr.
A-Einträge und TXT teilen sich kein Publikum
Die beiden Eintragstypen werden unter unterschiedlichen Bedingungen beantwortet, und sie als einen Dienst zu behandeln ist der Fehler, den dieser Artikel verhindern soll.
| 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 |
Diese Asymmetrie ist Absicht und kein Versehen. Eine Namens-zu-Adress-Zuordnung ist für Außenstehende wenig wert, während Zertifikatsmetadaten die Identitäten in deinem Overlay beschreiben. Übernimm keine Annahme von einer Zeile in die andere, nur weil derselbe Prozess beides beantwortet.
Er antwortet nur über die eigenen Hosts des Leuchtturms
Dies ist kein allgemeiner Resolver für dein Büro, deine Cloud-VPC oder das öffentliche Internet. Der Leuchtturm antwortet aus Hostinformationen, die er bekommen hat, weshalb die Funktion auf Leuchtturm-Knoten lebt und nicht auf jedem Peer.
Wenn ein Name fehlschlägt, der nichts mit dem Overlay zu tun hat, finde die Zone und den Resolver, die ihn tatsächlich besitzen. Einen Overlay-Resolver in die allgemeine DNS-Konfiguration eines Hosts zu mischen erzeugt Fehler, die zufällig wirken, weil manche Namen auflösen und andere von nichts beantwortet werden.
Achte auch auf den Bootstrap-Endpunkt. Ein Hostname, der zum Erreichen des ersten Leuchtturms dient, muss über einen gewöhnlichen Pfad auflösen, bevor die Erkennung darauf bauen kann, also sieht ein Henne-Ei-Problem hier genau wie ein kaputtes Overlay aus. Es meldet sich sogar gleich: ein Peer, der nie hochkommt, und kein offensichtlicher Grund. Prüfe die Namensauflösung, bevor du Zertifikate anfasst, denn diese Reihenfolge erwischt Leute, die mit der schwierigeren Hälfte angefangen haben.
Prüfe die Bind-Adresse und teste dann von außen
lighthouse.dns.host und lighthouse.dns.port entscheiden, wo der optionale Dienst lauscht. Prüfe diese Werte zusammen mit der Host-Firewall und der Netzwerkrichtlinie, denn eine Bind-Adresse ist eine Absichtserklärung und keine Sicherheitskontrolle für sich.
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortFrage aus den Netzen, die du zulassen willst, nicht vom Leuchtturm selbst. Ein erfolgreicher Lookup auf dem Leuchtturm beweist, dass der Prozess läuft, und sagt dir nichts darüber, was ein externer Host fragen kann, und das ist die Frage, die wirklich zählt.
Stelle ihn bewusst bereit
Namen und Zertifikatsmetadaten sind nützliche Betriebsinformationen, und Nützlichkeit schneidet in beide Richtungen. Entscheide, ob der Listener nur für das Overlay gelten soll, welche Eintragstypen erlaubt sind und wer die Konfiguration prüft, wenn sie sich ändert.
Schreib es dann neben die Leuchtturm-Einstellungen. Die nächste Person, die einen Auflösungsfehler debuggt, wird sonst annehmen, der Dienst sei immer da gewesen. Sie wird auch annehmen, er sei immer von dort erreichbar gewesen, wo sie zufällig testet. Ein Absatz mit Bind-Adresse, erlaubten Netzen und Eintragstypen spart dieser Person einen Nachmittag und dir eine Nachricht mit der Frage, warum sich etwas geändert hat.