Geteiltes DNS testen, ohne interne Namen zu verraten

Wer einen öffentlichen Resolver nach einem internen Namen fragt, verrät den Namen und umgeht die Regel, die getestet werden sollte. Die Anfrage erreicht einen Server, den man nicht kontrolliert, die Antwort stammt aus einem Namensraum, der sie nie hätte sehen dürfen, und das Ergebnis sagt nichts darüber aus, ob geteiltes DNS funktioniert. Geteiltes DNS zu testen bedeutet, den Resolver-Pfad zu testen, den eine Anwendung tatsächlich nutzt. Dieser Pfad wird vom Betriebssystem gewählt, von der Domänenliste im VPN-Profil und manchmal vom Browser.

Zwei Namen wählen und beide Antworten vorher vorhersagen

Bitten Sie den Netzwerkverantwortlichen um einen dokumentierten internen Testnamen und wählen Sie einen gewöhnlichen öffentlichen Namen, der nichts über die Organisation verrät. Schreiben Sie vor dem ersten Versuch auf, was für jeden der beiden passieren soll: Der interne Name soll den Resolver des Tunnels erreichen und eine interne Adresse zurückgeben, während der öffentliche Name über den Resolver aufgelöst werden soll, den das System normalerweise nutzt. Diese beiden Vorhersagen sind der Test, denn ohne sie lässt sich jede Antwort im Nachhinein rationalisieren. Halten Sie das Paar über mehrere Läufe konstant, damit ein späterer Vergleich etwas bedeutet.

Prüfen Sie die tatsächlich wirksamen Regeln und nicht die beabsichtigten. Die Domänenliste, die an der VPN-Verbindung hängt, entscheidet, welche Suffixe an welchen Resolver gehen, und ein Tippfehler in dieser Liste erzeugt eine plausible, aber falsche Aufteilung. Auf einem verwalteten Gerät nutzen Sie den Diagnosepfad des Administrators, da lokale Überschreibungen bei der nächsten Prüfung durch eine Richtlinie zurückgesetzt werden können.

Notieren Sie die Vorhersage neben der beobachteten Antwort im selben Ticket. Ein Test ohne Vorhersage kann nicht scheitern, und ein Test, der nicht scheitern kann, lehrt nichts.

Den Pfad der Anwendung testen, nicht einen selbst gewählten Server

Ein Befehl, der einen Resolver ausdrücklich nennt, testet genau diesen Resolver und sonst nichts. Er sagt, ob der interne Server antwortet, was nützlich ist, und er sagt nicht, ob eine Anwendung den Namen dorthin schickt. Testen Sie zuerst über den normalen Pfad: Lösen Sie den internen Namen so auf, wie es eine Anwendung täte, und lösen Sie danach den öffentlichen Namen genauso auf. Erst danach fragen Sie gezielt einzelne Server ab, um zu finden, wo das Verhalten abweicht.

Browser erschweren das Bild, weil Einstellungen für sicheres DNS den System-Resolver vollständig umgehen können. Ein Browser, der mit einem eigenen verschlüsselten Resolver konfiguriert ist, sieht die Aufteilung nie, und der Fehler sieht wie ein defektes VPN-Profil aus. Prüfen Sie diese Einstellung, bevor Sie den Tunnel ändern.

Wiederholen Sie die Abfrage nach dem Neuverbinden, wenn die Wiederherstellung die Frage ist. Eine Antwort aus dem Cache von vor dem Neuverbinden kann eine korrekt wiederhergestellte Aufteilung besser oder schlechter aussehen lassen, als sie ist.

Die Antwortkategorie festhalten, nicht nur Erfolg oder Fehler

Schreiben Sie auf, welches der vier Dinge eingetreten ist: eine interne Adresse, eine öffentliche Adresse, eine negative Antwort oder eine Zeitüberschreitung. Jede bedeutet etwas anderes. Eine interne Adresse für den internen Namen ist der erwartete Erfolg; eine öffentliche Adresse für einen internen Namen deutet darauf hin, dass die Anfrage den Tunnel verlassen hat; eine negative Antwort des autoritativen Servers weist auf einen fehlenden Datensatz hin und nicht auf einen Routingfehler; und eine Zeitüberschreitung spricht für Erreichbarkeitsprobleme oder einen Resolver, der die Anfrage nie erhalten hat. Erfolg und Fehler sind zu grob, um darauf zu reagieren.

Berücksichtigen Sie den Cache, bevor Sie eine fehlende frische Abfrage interpretieren, denn eine negative Antwort im Cache sieht genauso aus wie ein Name, der nicht existiert. Halten Sie die Antwort fest, bevor Sie etwas über unterstützte Mittel löschen, denn die erste Antwort ist der Beweis.

Die beiden Zweige ohne Raten deuten

Löst der interne Name korrekt auf und die Anwendung scheitert trotzdem, hat der Resolver seine Aufgabe erfüllt, und die nächsten Verdächtigen sind Routen und Berechtigungen auf der Ressource selbst. Hat der private Name einen öffentlichen Resolver erreicht, wird die Aufteilungsregel auf diese Abfrage nicht angewendet; prüfen Sie daher die Domänenliste und jede Browser-Richtlinie mit dem Eigentümer des Namensraums. Diese beiden Zweige haben verschiedene Eigentümer, und deshalb ist es wichtiger festzuhalten, welchen man gesehen hat, als festzuhalten, dass etwas kaputt ist.

Schwärzen Sie die geteilte Ausgabe, aber behalten Sie die Struktur: welcher Namensraum, welche Regel, welche Antwortkategorie. Eine Resolver-Antwort kann interne Adressen und Hostnamen enthalten, und ein Ticket ist für beides ein dauerhaftes Zuhause.

Geben Sie das Ergebnis dann an den Eigentümer des Namensraums weiter, mit den beiden beobachteten Kategorien und ohne die Namen. Das ist ein Gespräch von fünf Minuten statt einer Woche Spekulation.