VPN-DNS-Bericht: Was hineingehört, damit er reproduzierbar ist

„DNS ist kaputt“ ist eine Schlussfolgerung, und zwar keine, auf deren Grundlage ein Helfer etwas tun kann. Der brauchbare Teil eines Berichts ist die Form des Fehlers: welcher Name, über welchen Resolver, mit welcher Antwort. Drei Details machen aus einer Beschwerde etwas Reproduzierbares, und alle drei lassen sich gefahrlos teilen, sobald die privaten Teile umbenannt sind. Es folgt das Minimum, das ein VPN-DNS-Bericht braucht, bevor jemand helfen kann.

Eine Kategorie von Name, kein Urteil

Beginnen Sie mit dem Namen selbst und ordnen Sie ihn ein: öffentlich, intern, kurz, vollqualifiziert oder von einem bestimmten Suffix bedient. Ein interner Name, der scheitert, während öffentliche Namen aufgelöst werden, deutet auf die Resolver-Auswahl hin und nicht auf die Erreichbarkeit. Scheitert jeder Name, deutet das auf den Pfad zum Resolver hin, und das ist eine andere Untersuchung mit anderen Beweisen. Die Kategorie trägt die Diagnose, und die genaue Zeichenkette lässt sich schwärzen.

Sagen Sie, ob der Fehler einen aufgebauten Tunnel braucht oder erst nach dessen Trennung auftritt. Ein Name, der nur bei aktivem VPN bricht, spricht für die Konfiguration pro Verbindung, während einer, der nach dem Trennen bricht, für zurückgebliebenen Zustand spricht. Berichte lassen das meist weg und wundern sich dann, warum der erste Vorschlag nicht hilft.

Den Resolver-Pfad festhalten

Eine Abfrage an einen ausdrücklich gewählten Server und der gewöhnliche Lookup einer Anwendung sind verschiedene Experimente. Sagen Sie, welches davon den Fehler erzeugt hat, denn eine manuelle Abfrage an einen funktionierenden Server beweist nur, dass der Server funktioniert. Die Befehle unten trennen den Systempfad von einer direkten Frage.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

Die Statusausgabe nennt die Server pro Verbindung und die Routing-Domänen, also wo Split-DNS entschieden wird. Der getent-Aufruf folgt demselben Pfad wie die Anwendung, einschließlich der nsswitch-Reihenfolge. Die direkte Abfrage umgeht beides und prüft einen Server isoliert. Berichten Sie, welcher der drei gescheitert und welcher gelungen ist, und der Leser muss den Pfad nicht mehr raten.

Den kontrollierten Vergleich angeben

Ändern Sie eine Variable und sagen Sie, was sich geändert hat. Dass öffentliche Namen aufgelöst werden, während interne scheitern, ist ein Auswahlproblem; dass jeder Name in einen Timeout läuft, ist ein Pfadproblem; und ein privater Name, der auf eine öffentliche Adresse auflöst, ist ein Leck in den falschen Resolver. Zwei dieser drei haben nichts damit zu tun, ob der Tunnel aufgebaut ist. Ein Bericht, der behauptet, alle Abfragen seien kaputt, enthält meist einen Vergleich, der nie durchgeführt wurde.

Trennen Sie Auflösung von Zustellung. Wenn der Name aufgelöst wird und die Seite trotzdem scheitert, war die DNS-Stufe erfolgreich, und der Bericht sollte das sagen, denn der nächste Schritt ist eine Route oder ein Listener und kein Resolver. Diese eine Unterscheidung spart häufiger eine Fragerunde als jeder Protokollauszug.

Den Namensraum schwärzen, die Beziehungen behalten

Interne Namen lassen sich ersetzen, solange die Ersetzungen die Struktur erhalten. Ordnen Sie jedem eigenen Server und Suffix ein stabiles Label zu und halten Sie diese Zuordnung aus der geteilten Kopie heraus. Jeden internen Host durch denselben Platzhalter zu ersetzen zerstört genau den Beweis, den der Bericht braucht, weil der Leser nicht mehr sieht, dass ein Suffix aufgelöst wurde und ein anderes nicht. Dieselbe Regel gilt für Adressen: Behalten Sie die Präfix-Beziehungen und ändern Sie die Host-Bits, wenn die Richtlinie es verlangt.

Senden Sie den Datensatz über den verifizierten Kanal und lassen Sie weg, was die Diagnose nie braucht. Passwörter, private Schlüssel und fremde Firmennamen gehören nicht zu einer DNS-Frage. Was der Leser braucht, ist die Fehlerkategorie, der Resolver-Pfad, der genaue Fehler und der eine Vergleich, den Sie durchgeführt haben.