Split-DNS-Mitschnitt: Sagen Sie, wo jede Beobachtung gemacht wurde

Zwei Personen untersuchen dasselbe Split-DNS-Problem und erhalten unterschiedliche Resolver-Adressen. Eine nutzte ein Suchwerkzeug, eine andere zeichnete Pakete am Adapter auf, und eine dritte las die Diagnose des Clients selbst. Keiner von ihnen lügt, und keiner beschreibt dieselbe Stufe. Benennt man den Beobachtungspunkt, wird aus einem Widerspruch eine Karte.

Eine Auflösung, mehrere Beobachtungspunkte

Für einen einzigen internen Namen gibt es mindestens fünf Stellen zum Nachsehen: die Anwendung und die Resolver-API, die sie aufruft, die wirksame Domänenrichtlinie auf dem Client, ein Mitschnitt am Adapter oder Filter, eine kontrollierte Gateway-Grenze und der Resolver, der die Anfrage tatsächlich empfängt.

Jede beantwortet eine andere Frage, und keine allein belegt, wohin die Anfrage gegangen ist.

Ein Mitschnitt am Adapter zeigt Pakete, keine Absicht. Er sagt nicht, welchen Resolver der Client gewählt hat, und ein leerer Mitschnitt kann eine zwischengespeicherte Antwort oder eine andere Resolver-API bedeuten statt eines verworfenen Pakets. Behandeln Sie jede Beobachtung als Beleg für eine Stufe. Setzen Sie dann die Stufen zu einem Pfad zusammen.

Der Filter des Clients sitzt zwischen Anwendung und Leitung

Ein VPN-Client mit Split-DNS wendet die Domänenabgleichung an, bevor das Paket den Rechner verlässt. Namen im getunnelten Suffix gehen an den internen Resolver; alles andere geht an den lokalen. Der Filter ist Richtlinie, und die Richtlinie kann je nach Plattform und Clientversion abweichen.

Die Split-DNS-Hinweise für Secure Client von Cisco behandeln die Domänenabgleichung und den Windows-Filter und trennen das, was eine Anwendung sieht, wenn sie die native Resolver-API nutzt, von dem, was ein Werkzeug wie nslookup sieht. Genau diese Unterschiede sind der Punkt.

Beginnen Sie mit dem wirksamen Profil und einer gewöhnlichen Auflösung durch die Anwendung. Jeder Test, der einen bestimmten Server nennt, ist ein bewusster Umweg; erklären Sie ihn mit der Diagnose des Clients selbst, und lassen Sie ihn nicht zum Abnahmekriterium werden.

nslookup geht einen anderen Weg als die Anwendung

nslookup baut seine eigene DNS-Anfrage und kann die Resolver-Richtlinie des Betriebssystems umgehen. Das macht es zu einem nützlichen Werkzeug, um einem bestimmten Server eine bestimmte Frage zu stellen, und zu einem irreführenden Werkzeug, um zu prüfen, was eine Anwendung erleben wird.

Unter Windows entscheidet die Richtlinientabelle für die Namensauflösung, welches Suffix welchen Server verwendet. Liest man sie, zeigt sich die Richtlinie, der die Anwendung folgen wird, und das ist oft das fehlende Teil.

Lesen Sie die Richtlinie und stellen Sie dann dieselbe Frage über den normalen Resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Verschlüsselte Resolver verbergen die Anfrage, nicht die Verbindung

Ein Browser mit eigenem DNS-over-HTTPS-Resolver ist ein ganz anderer Fall. Die Anfrage verlässt den Rechner innerhalb von TLS, sodass ein Paketmitschnitt eine Verbindung zu einer Resolver-Adresse zeigt, aber nicht den gefragten Namen.

Ermitteln Sie zuerst die verwaltete Richtlinie des Browsers und vergleichen Sie sie dann mit einer Auflösung durch das Betriebssystem. Ein Browser, der seinen eigenen Resolver wählen darf, sieht die Split-DNS-Richtlinie vielleicht überhaupt nicht.

Dieselbe Vorsicht gilt für jeden Client, der seinen eigenen Resolver mitbringt. Ein Mitschnitt, der die entfernte Verbindung erkennt, ist kein Beleg für den Anfragenamen. Wenn Sie den Namen brauchen, holen Sie ihn aus den Protokollen des Resolvers selbst oder aus der Diagnose der Anwendung, unter den geltenden Datenschutzregeln.

Vergleichen Sie mit einem gekennzeichneten Test

Wählen Sie einen genehmigten internen Namen für den Test sowie einen öffentlichen Namen ohne sensible Bedeutung. Notieren Sie für jeden die Zeit, den Datensatztyp, die Antwort und die erwartete Richtlinie.

Wo es erlaubt ist, vergleichen Sie den Empfang im Resolver mit einer eng begrenzten Beobachtung am Client oder Gateway:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Senden Sie niemals private Namen an unabhängige öffentliche Resolver, nur um einen Vergleich herzustellen, und schwärzen Sie alles, was Sie teilen. Trennen Sie schließlich eine korrekte DNS-Antwort von der anschließenden Dienstverbindung: Die aufgelöste private Adresse braucht weiterhin eine Route und eine Anwendungsfreigabe.