Zwei DNS-Server an einem Adapter trennen keine Namespaces

Zwei Resolver an einem Adapter aufzulisten sieht nach einem Weg aus, eine Domäne an einen Server und eine andere Domäne an den anderen zu schicken, und nichts an der Resolverliste funktioniert so. Windows löst nach Namen auf, und die Entscheidung, welcher Server gefragt wird, kommt aus Richtlinienobjekten statt aus einer geordneten Adressliste. Das Denkmodell, das ersetzt werden muss, ist die Warteschlange: Es gibt keinen ersten Server für Domäne A und keinen zweiten Server für Domäne B. Es gibt einen Regelsatz pro Namespace, der die Server ausdrücklich benennt, und sobald diese Regeln existieren, ist die Adapterliste nicht mehr interessant.

Der Mythos: Zwei Adressen teilen zwei Domänen

Der Glaube hält sich, weil er zufällig funktioniert, wenn ein Server alles beantwortet und der zweite nur ein Ausweichpfad ist. Ein Client fragt den ersten Server, dieser leitet weiter oder fragt rekursiv, und die Antwort kommt an; niemand bemerkt, welcher Resolver die Zone tatsächlich hielt. Die Illusion zerbricht in dem Moment, in dem die beiden Namespaces in getrennten privaten Zonen ohne Weiterleitung zwischen ihnen liegen, weil der erste Server dann autoritativ antwortet, dass der Name nicht existiert. Eine negative Antwort des ersten Servers löst keinen Ausweichpfad aus, da der Client eine endgültige Antwort und keinen Fehler erhalten hat.

Eine geordnete Liste kennt keinen Begriff von Domäne und kann die Absicht daher nicht ausdrücken. Was die Liste wirklich steuert, ist, welcher Server zuerst gefragt und welcher als zweites versucht wird, und beide Antworten gelten für jeden Namen gleichermaßen.

Was Windows zur Auswahl tatsächlich verwendet

Die Namensauflösungs-Richtlinientabelle gleicht einen Namen mit konfigurierten Namespaces ab und wählt die Server und Optionen für diese Übereinstimmung. Regeln können lokal konfiguriert, über Gruppenrichtlinien verteilt oder durch ein VPN-Profil bereitgestellt werden, und die effektive Richtlinie ist eine Kombination statt einer einzigen Liste. Deshalb ist die erste Diagnose immer der effektive Zustand: Eine lokal angelegte Regel, die gegen eine verwaltete Richtlinie verliert, erzeugt ein Labor, das sich ganz anders verhält, als seine Konfiguration vermuten lässt. Regeln werden zudem nach Spezifität abgeglichen, sodass ein breiter Namespace-Eintrag einen engen auf eine Weise überschatten kann, die in einer Liste konfigurierter Einträge unsichtbar ist. Die effektive Reihenfolge zu lesen ist der einzige Weg zu sehen, welche Regel gewinnt.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Der erste Befehl listet auf, was auf dem Rechner konfiguriert ist; der zweite zeigt, was der Client tatsächlich anwenden wird, einschließlich Einträgen, die von anderswo kamen. Wenn die effektive Ausgabe verwaltete Namespaces enthält, ist der Eigentümer dieser Richtlinie die richtige Stelle, um die Änderung zu beantragen, nicht die lokale Regelliste. Beide Befehle lesen nur Zustand, daher kostet es nichts, sie auszuführen, bevor sich jemand auf die Änderung einigt.

Eine Regel pro Namespace, das Objekt behalten

Nachdem der effektive Zustand verstanden ist, legen Sie eine Regel pro Namespace an und bewahren Sie das Objekt auf, das jeder Befehl zurückgibt. Anzeigenamen sind Etiketten für Menschen, und die eindeutige Kennung im zurückgegebenen Objekt ist danach das verlässliche Löschziel. Schreiben Sie beide Kennungen in dieselbe Änderungsnotiz, die die Namespaces und Resolver festhält, denn die Sitzung, die sie angelegt hat, wird nicht die Sitzung sein, die aufräumt.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

Der führende Punkt kennzeichnet eine Suffix-Übereinstimmung, die Regel deckt also app.svc.internal.example und alles darunter ab. Die beiden Adressen hier gehören zum eigenen Routingplan dieses Labors; eine Regel legt keine Zone an, installiert keine Route und autorisiert nicht die Anwendung, die sich schließlich verbindet, und die Referenz zu Add-DnsClientNrptRule dokumentiert genau, welcher Parameter was bewirkt.

Beachten Sie, was diese Befehle nicht tun: Sie gelten rechnerweit, sind nicht auf eine VPN-Sitzung beschränkt und überleben das Schließen des Fensters. Ein Labor, das dies vergisst, hinterlässt Richtlinien, nachdem der Tunnel weg ist.

Beweisen Sie, dass der Client den Server gewählt hat

Einen bestimmten Server zu fragen, ob er einen Namen kennt, beweist, dass der Server antworten kann, was nicht dieselbe Aussage ist wie die, dass der Client diesen Server gewählt hat. Der Test, auf den es ankommt, löst einen echten Namen über den gewöhnlichen Client-Pfad auf und bestätigt dann, welcher Resolver ihn bearbeitet hat, idealerweise während der Tunnel, der die Route liefert, steht. Ist der Tunnel unten, zeigt eine korrekt eingegrenzte Regel weiterhin auf einen nicht erreichbaren Server, was ein Routingproblem und kein Richtlinienproblem ist. Testen Sie beide Zustände, damit sie später unterschieden werden können.

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

Achten Sie auf zwischengespeicherte Antworten aus der Zeit vor den Regeln und auf Anwendungen, die den Systemresolver mit ihrem eigenen verschlüsselten DNS völlig umgehen. Suchsuffixe sind eine weitere eigene Funktion: Eine Regel kann einen Resolver für einen vollständigen Namen wählen, ohne Windows beizubringen, einen bloßen Hostnamen in diesen Namespace zu erweitern.

Entfernen Sie genau das, was Sie angelegt haben

Beim Aufräumen wird aus einem Labor eine warnende Geschichte. Jede Regel auf dem Rechner zu löschen ist schnell und entfernt Richtlinien, auf die jemand anderes angewiesen ist, also verwenden Sie die Kennungen, die beim Anlegen der Regeln erfasst wurden, und lesen Sie danach den effektiven Zustand erneut, um zu bestätigen, dass der Rechner dorthin zurückgekehrt ist, wo er begonnen hat. Ist die Sitzung, die sie angelegt hat, nicht mehr da, ist die Änderungsnotiz der einzige Ort, an dem die Kennungen existieren. Das ist der Grund, sie vor dem ersten Befehl aufzuschreiben und nicht danach.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

Bei einem Rollout statt einem Labor zählt die Frage der Lebensdauer ebenso wie die Regel. Ein VPN-Profil kann die Namespace-Regeln mitführen und wählen, ob sie über die Verbindung hinaus bestehen bleiben; eine Regel, die bestehen bleibt, während der Resolver nicht erreichbar ist, lässt Clients einen toten Server bevorzugen, und eine verbindungsgebundene Regel verschwindet mit dem Tunnel. Entscheiden Sie, welches dieser Verhaltensweisen der Dienst braucht, markieren Sie, wem die Regel gehört, und lassen Sie die Aufteilung der Zuständigkeit neben dem Profil dokumentiert, statt in jemandes Erinnerung an ein Labor.