Twee DNS-servers op één adapter splitsen geen naamruimten

Twee resolvers op één adapter vermelden lijkt een manier om het ene domein naar de ene server en een ander domein naar de andere te sturen, en niets in de resolverslijst werkt zo. Windows lost op naar naam, en de beslissing welke server wordt gevraagd komt uit beleidsobjecten in plaats van uit een geordende adressenlijst. Het denkmodel dat vervangen moet worden is de wachtrij: er is geen eerste server voor domein A en geen tweede server voor domein B. Er is een regelset per naamruimte die de servers expliciet noemt, en zodra die regels bestaan, is de adapterlijst niet meer interessant.

De mythe: twee adressen splitsen twee domeinen

De overtuiging blijft bestaan omdat ze bij toeval werkt wanneer één server alles beantwoordt en de tweede alleen een terugvaloptie is. Een client vraagt de eerste server, die server stuurt door of doet recursie, en het antwoord komt aan; niemand merkt welke resolver de zone werkelijk had. De illusie breekt op het moment dat de twee naamruimten in gescheiden privézones leven zonder doorsturing daartussen, omdat de eerste server dan gezaghebbend antwoordt dat de naam niet bestaat. Een negatief antwoord van de eerste server activeert de terugvaloptie niet, omdat de client een definitief antwoord heeft gekregen en geen fout.

Een geordende lijst heeft geen begrip van een domein, dus kan ze de bedoeling niet uitdrukken. Wat de lijst werkelijk beheert, is welke server eerst wordt gevraagd en welke als tweede wordt geprobeerd, en beide antwoorden gelden evenzeer voor elke naam.

Wat Windows werkelijk gebruikt om te kiezen

De tabel voor naamoplossingsbeleid koppelt een naam aan geconfigureerde naamruimten en selecteert de servers en opties voor die overeenkomst. Regels kunnen lokaal worden geconfigureerd, via groepsbeleid worden geleverd of door een VPN-profiel worden aangeleverd, en het effectieve beleid is een combinatie en niet één lijst. Daarom is de eerste diagnose altijd de effectieve toestand: een lokaal gemaakte regel die verliest van een beheerd beleid levert een lab op dat zich heel anders gedraagt dan de configuratie suggereert. Regels worden ook op specificiteit gematcht, zodat een brede naamruimte-invoer een smalle kan overschaduwen op manieren die onzichtbaar zijn in een lijst met geconfigureerde items. De effectieve volgorde lezen is de enige manier om te zien welke regel wint.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

De eerste opdracht somt op wat op de machine is geconfigureerd; de tweede toont wat de client werkelijk zal toepassen, inclusief vermeldingen die van elders kwamen. Als de effectieve uitvoer beheerde naamruimten bevat, is de eigenaar van dat beleid de juiste plek om de wijziging te vragen, niet de lokale regellijst. Beide opdrachten lezen alleen toestand, dus ze uitvoeren voordat iemand met de wijziging instemt kost niets.

Eén regel per naamruimte, bewaar het object

Zodra de effectieve toestand begrepen is, maakt u één regel per naamruimte en bewaart u het object dat elke opdracht teruggeeft. Weergavenamen zijn etiketten voor mensen, en de unieke identificatie in het teruggegeven object is daarna het betrouwbare verwijderdoel. Schrijf beide identificaties in dezelfde wijzigingsnotitie die de naamruimten en resolvers vastlegt, want de sessie die ze heeft gemaakt is niet de sessie die opruimt.

$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

De voorloopstip markeert een suffixovereenkomst, dus de regel dekt app.svc.internal.example en al het andere eronder. De twee adressen hier horen bij het eigen routeringsplan van dit lab; een regel maakt geen zone, installeert geen route en machtigt de toepassing die uiteindelijk verbindt niet, en de referentie van Add-DnsClientNrptRule documenteert precies welke parameter wat doet.

Let op wat deze opdrachten niet doen: ze zijn machinebreed, ze zijn niet beperkt tot een VPN-sessie, en ze overleven het sluiten van het venster. Een lab dat dit vergeet laat beleid achter nadat de tunnel weg is.

Bewijs dat de client de server heeft gekozen

Een specifieke server vragen of hij een naam kent bewijst dat de server kan antwoorden, wat niet dezelfde bewering is als dat de client die server heeft gekozen. De test die ertoe doet, lost een echte naam op via het gewone clientpad en bevestigt daarna welke resolver die heeft afgehandeld, idealiter terwijl de tunnel die de route levert actief is. Als de tunnel uit staat, wijst een correct afgebakende regel nog steeds naar een onbereikbare server, en dat is een routeringsprobleem en geen beleidsprobleem. Test beide toestanden zodat ze later te onderscheiden zijn.

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

Let op gecachte antwoorden uit de periode voordat de regels bestonden, en let op toepassingen die de systeemresolver volledig omzeilen met hun eigen versleutelde DNS. Zoeksuffixen zijn weer een aparte functie: een regel kan een resolver kiezen voor een volledige naam zonder Windows te leren een kale hostnaam in die naamruimte uit te breiden.

Verwijder precies wat u hebt gemaakt

Opruimen is waar een lab een waarschuwend verhaal wordt. Elke regel op de machine verwijderen is snel en haalt beleid weg waarop iemand anders vertrouwt, dus gebruik de identificaties die zijn vastgelegd bij het maken van de regels, en lees daarna de effectieve toestand opnieuw om te bevestigen dat de machine terug is waar ze begon. Als de sessie die ze heeft gemaakt weg is, is de wijzigingsnotitie de enige plek waar de identificaties bestaan. Daarom worden ze opgeschreven voordat de eerste opdracht loopt, en niet daarna.

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

Voor een uitrol en niet voor een lab telt de levensduurvraag even zwaar als de regel. Een VPN-profiel kan de naamruimteregels dragen en kiezen of ze na de verbinding blijven bestaan; een regel die blijft bestaan terwijl de resolver onbereikbaar is, laat clients een dode server verkiezen, en een aan de verbinding gebonden regel verdwijnt wanneer de tunnel dat doet. Beslis welk van die gedragingen de dienst nodig heeft, markeer wie de regel bezit, en laat de verdeling van bevoegdheid gedocumenteerd naast het profiel in plaats van in iemands herinnering aan een lab.