To DNS-servere på én adapter deler ikke navnerom

Å liste to resolvere på én adapter ser ut som en måte å sende ett domene til én server og et annet domene til den andre, og ingenting i resolverlisten fungerer slik. Windows løser opp etter navn, og beslutningen om hvilken server som skal spørres kommer fra policyobjekter i stedet for fra en ordnet adresseliste. Mentalmodellen som må erstattes, er køen: det finnes ingen første server for domene A og ingen andre server for domene B. Det finnes et regelsett per navnerom som navngir serverne eksplisitt, og når disse reglene først finnes, slutter adapterlisten å være interessant.

Myten: to adresser deler to domener

Troen overlever fordi den fungerer ved et uhell når én server svarer på alt og den andre bare er en reserve. En klient spør den første serveren, den serveren videresender eller rekurserer, og svaret kommer; ingen legger merke til hvilken resolver som egentlig hadde sonen. Illusjonen brister i det øyeblikket de to navnerommene lever i atskilte private soner uten videresending mellom seg, fordi den første serveren da svarer autoritativt at navnet ikke finnes. Et negativt svar fra den første serveren utløser ikke reserven, siden klienten har fått et endelig svar og ikke en feil.

En ordnet liste har ikke noe begrep om domene, så den kan ikke uttrykke intensjonen. Det listen egentlig styrer, er hvilken server som spørres først og hvilken som prøves som nummer to, og begge svarene gjelder likt for hvert navn.

Hva Windows faktisk bruker for å velge

Tabellen for navneoppløsningspolicy matcher et navn mot konfigurerte navnerom og velger serverne og alternativene for det treffet. Regler kan konfigureres lokalt, leveres av gruppepolicy eller gis fra en VPN-profil, og den effektive policyen er en kombinasjon og ikke én liste. Derfor er den første diagnostikken alltid den effektive tilstanden: en lokalt opprettet regel som taper mot en administrert policy gir et laboratorium som oppfører seg helt annerledes enn konfigurasjonen tilsier. Regler matches også etter spesifisitet, så en bred navneromsoppføring kan overskygge en smal på måter som er usynlige i en liste over konfigurerte elementer. Å lese den effektive rekkefølgen er den eneste måten å se hvilken regel som vinner.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Den første kommandoen viser hva som er konfigurert på maskinen; den andre viser hva klienten faktisk vil bruke, inkludert oppføringer som kom fra andre steder. Hvis den effektive utskriften inneholder administrerte navnerom, er eieren av den policyen det riktige stedet å be om endringen, ikke den lokale regellisten. Begge kommandoene leser bare tilstand, så det koster ingenting å kjøre dem før noen er enige om endringen.

Én regel per navnerom, ta vare på objektet

Når den effektive tilstanden er forstått, opprett én regel per navnerom og ta vare på objektet hver kommando returnerer. Visningsnavn er etiketter for mennesker, og den unike identifikatoren i det returnerte objektet er det pålitelige slettepunktet etterpå. Skriv begge identifikatorene i samme endringsnotat som registrerer navnerommene og resolverne, fordi økten som opprettet dem ikke blir økten som rydder opp.

$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

Den ledende prikken markerer suffikstreff, så regelen dekker app.svc.internal.example og alt annet under det. De to adressene her tilhører dette laboratoriets egen rutingplan; en regel oppretter ikke en sone, installerer ikke en rute og autoriserer ikke applikasjonen som til slutt kobler til, og den referansen for Add-DnsClientNrptRule dokumenterer nøyaktig hvilken parameter som gjør hva.

Legg merke til hva disse kommandoene ikke gjør: de er maskinbrede, de er ikke begrenset til en VPN-økt, og de overlever at vinduet lukkes. Et laboratorium som glemmer dette, etterlater policy når tunnelen er borte.

Bevis at klienten valgte serveren

Å spørre en bestemt server om den kjenner et navn beviser at serveren kan svare, noe som ikke er samme påstand som at klienten valgte den serveren. Testen som betyr noe, løser et ekte navn gjennom klientens vanlige vei og bekrefter deretter hvilken resolver som håndterte det, helst mens tunnelen som leverer ruten er oppe. Hvis tunnelen er nede, peker en korrekt avgrenset regel fortsatt på en utilgjengelig server, og det er et rutingproblem og ikke et policyproblem. Test begge tilstandene slik at de kan skilles senere.

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

Følg med på hurtigbufrede svar fra perioden før reglene, og følg med på applikasjoner som omgår systemresolveren helt med sin egen krypterte DNS. Søkesuffikser er en annen separat funksjon: en regel kan velge en resolver for et fullstendig navn uten å lære Windows å utvide et bart vertsnavn til det navnerommet.

Fjern nøyaktig det du opprettet

Opprydding er stedet der et laboratorium blir en advarende historie. Å slette hver regel på maskinen er raskt og fjerner policy som noen andre er avhengig av, så bruk identifikatorene som ble fanget opp da reglene ble opprettet, og les den effektive tilstanden på nytt etterpå for å bekrefte at maskinen er tilbake der den startet. Hvis økten som opprettet dem er borte, er endringsnotatet det eneste stedet identifikatorene finnes. Det er grunnen til å skrive dem ned før den første kommandoen kjører, ikke etterpå.

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

For en utrulling og ikke et laboratorium betyr levetidsspørsmålet like mye som regelen. En VPN-profil kan bære navneromsreglene og velge om de vedvarer utover tilkoblingen; en regel som vedvarer mens resolveren er utilgjengelig, får klienter til å foretrekke en død server, og en tilkoblingsavgrenset regel forsvinner når tunnelen gjør det. Bestem hvilken av disse oppførselene tjenesten trenger, marker hvem som eier regelen, og la fordelingen av myndighet være dokumentert ved siden av profilen i stedet for i noens minne om et laboratorium.