To DNS-servere på én adapter opdeler ikke navnerum

At liste to resolvere på én adapter ser ud som en måde at sende ét domæne til én server og et andet domæne til den anden, og intet i resolverlisten fungerer sådan. Windows opløser efter navn, og beslutningen om hvilken server der skal spørges, kommer fra politikobjekter i stedet for fra en ordnet adresseliste. Den mentale model, der skal erstattes, er køen: der er ingen første server for domæne A og anden server for domæne B. Der er et regelsæt for hvert navnerum, som navngiver serverne eksplicit, og når først disse regler findes, holder adapterlisten op med at være interessant.

Myten: to adresser deler to domæner

Troen overlever, fordi den fungerer ved et tilfælde, når én server tilfældigvis svarer på alt, og den anden kun er en reserve. En klient spørger den første server, den server videresender eller rekurserer, og svaret ankommer; ingen bemærker, hvilken resolver der egentlig havde zonen. Illusionen brister i det øjeblik, de to navnerum lever i adskilte private zoner uden videresendelse mellem sig, fordi den første server så svarer autoritativt, at navnet ikke findes. Et negativt svar fra den første server udløser ikke reserven, da klienten har fået et definitivt svar og ikke en fejl.

En ordnet liste har intet begreb om et domæne, så den kan ikke udtrykke hensigten. Det, listen reelt styrer, er hvilken server der spørges først, og hvilken der prøves som nummer to, og begge svar gælder lige meget for ethvert navn.

Hvad Windows faktisk bruger til at vælge

Tabellen over navneopløsningspolitik matcher et navn mod konfigurerede navnerum og vælger serverne og indstillingerne for det match. Regler kan konfigureres lokalt, leveres af gruppepolitik eller komme fra en VPN-profil, og den effektive politik er en kombination i stedet for en enkelt liste. Derfor er den første diagnosticering altid den effektive tilstand: en lokalt oprettet regel, der taber til en administreret politik, giver et laboratorium, der slet ikke opfører sig som sin konfiguration. Regler matches også efter specificitet, så en bred navnerumspost kan overskygge en snæver på måder, der er usynlige i en liste over konfigurerede elementer. At læse den effektive rækkefølge er den eneste måde at se, hvilken regel der vinder.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Den første kommando viser, hvad der er konfigureret på maskinen; den anden viser, hvad klienten faktisk vil anvende, inklusive poster, der kom fra andre steder. Hvis det effektive output indeholder administrerede navnerum, er ejeren af den politik det rigtige sted at anmode om ændringen, ikke den lokale regelliste. Begge kommandoer læser kun tilstand, så det koster ingenting at køre dem, før nogen er enige om ændringen.

Én regel for hvert navnerum, gem objektet

Når den effektive tilstand er forstået, skal du oprette én regel for hvert navnerum og bevare det objekt, hver kommando returnerer. Visningsnavne er etiketter for mennesker, og den unikke identifikator i det returnerede objekt er det pålidelige slettermål bagefter. Skriv begge identifikatorer i samme ændringsnotat, som registrerer navnerummene og resolverne, fordi den session, der oprettede dem, ikke bliver den session, der rydder op.

$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

Det ledende punkt markerer et suffiksmatch, så reglen dækker app.svc.internal.example og alt andet under det. De to adresser her tilhører dette laboratoriums egen routingplan; en regel opretter ikke en zone, installerer ikke en rute og autoriserer ikke det program, der til sidst forbinder, og referencen for Add-DnsClientNrptRule dokumenterer præcis, hvilke parametre der gør hvad.

Bemærk, hvad disse kommandoer ikke gør: de er maskinbrede, de er ikke begrænset til en VPN-session, og de overlever, at vinduet lukkes. Et laboratorium, der glemmer dette, efterlader politik, når tunnelen er væk.

Bevis, at klienten valgte serveren

At spørge en bestemt server, om den kender et navn, beviser, at serveren kan svare, hvilket ikke er det samme som, at klienten vælger den server. Den test, der betyder noget, opløser et rigtigt navn ad klientens sædvanlige vej og bekræfter derefter, hvilken resolver der håndterede det, helst mens den tunnel, der leverer ruten, er oppe. Hvis tunnelen er nede, peger en korrekt afgrænset regel stadig på en utilgængelig server, hvilket er et routingproblem og ikke et politikproblem. Test begge tilstande, så de to kan skelnes senere.

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

Hold øje med cachelagrede svar fra perioden før reglerne, og hold øje med programmer, der helt omgår systemets resolver med deres egen krypterede DNS. Søgesuffikser er en anden separat funktion: en regel kan vælge en resolver til et fuldt navn uden at lære Windows at udvide et bart værtsnavn til det navnerum.

Fjern præcis det, du oprettede

Oprydning er det sted, hvor et laboratorium bliver en advarende historie. At slette hver regel på maskinen er hurtigt og fjerner politik, som nogen andre afhænger af, så brug identifikatorerne, der blev fanget, da reglerne blev oprettet, og læs den effektive tilstand igen bagefter for at bekræfte, at maskinen er tilbage, hvor den startede. Hvis den session, der oprettede dem, er væk, er ændringsnotatet det eneste sted, identifikatorerne findes. Det er grunden til at skrive dem ned, før den første kommando kører, og ikke efter.

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

For en udrulning i stedet for et laboratorium betyder levetidsspørgsmålet lige så meget som reglen. En VPN-profil kan bære navnerumsreglerne og vælge, om de varer ved ud over forbindelsen; en regel, der varer ved, mens resolverserveren er utilgængelig, får klienter til at foretrække en død server, og en forbindelsesafgrænset regel forsvinder, når tunnelen gør. Beslut, hvilken af disse adfærdsformer tjenesten har brug for, markér, hvem der ejer reglen, og lad opdelingen af myndigheden dokumentere ved siden af profilen i stedet for i nogens erindring om et laboratorium.