Twee DNS-bedieners op een adapter verdeel nie naamruimtes nie

Om twee oplossers op een adapter te lys lyk soos 'n manier om een domein na een bediener en 'n ander domein na die ander te stuur, en niks aan die oplosserlys werk so nie. Windows los op volgens naam, en die besluit oor watter bediener gevra word, kom uit beleidsobjekte eerder as uit 'n geordende adreslys. Die denkmodel wat vervang moet word, is die tou: daar is geen eerste bediener vir domein A en tweede bediener vir domein B nie. Daar is 'n reëlstel per naamruimte wat die bedieners eksplisiet noem, en sodra daardie reëls bestaan, hou die adapterlys op om interessant te wees.

Die mite: twee adresse verdeel twee domeine

Die oortuiging bly voortbestaan omdat dit per ongeluk werk wanneer een bediener toevallig alles beantwoord en die tweede net 'n terugval is. 'n Kliënt vra die eerste bediener, daardie bediener stuur aan of herhaal, en die antwoord kom aan; niemand merk watter oplosser die sone werklik gehad het nie. Die illusie breek op die oomblik wanneer die twee naamruimtes in aparte private sones woon sonder enige aansturing tussen hulle, want die eerste bediener antwoord dan gesaghebbend dat die naam nie bestaan nie. 'n Negatiewe antwoord van die eerste bediener is nie 'n terugval-sneller nie, want die kliënt het 'n definitiewe antwoord eerder as 'n mislukking ontvang.

'n Geordende lys het geen begrip van 'n domein nie, so dit kan nie die bedoeling uitdruk nie. Wat die lys werklik beheer, is watter bediener eerste gevra word en watter een tweede probeer word, en albei daardie antwoorde geld ewe veel vir elke naam.

Wat Windows werklik gebruik om te kies

Die Naamresolusiebeleidstabel pas 'n naam teen gekonfigureerde naamruimtes en kies die bedieners en opsies vir daardie passing. Reëls kan plaaslik gekonfigureer, deur Groepsbeleid gelewer of deur 'n VPN-profiel verskaf word, en die effektiewe beleid is 'n kombinasie eerder as 'n enkele lys. Dit is waarom die eerste diagnostiek altyd die effektiewe toestand is: 'n plaaslik geskepte reël wat teen 'n bestuurde beleid verloor, lewer 'n laboratorium wat niks soos sy konfigurasie optree nie. Reëls word ook volgens spesifisiteit gepas, so 'n breë naamruimte-inskrywing kan 'n smal een oorheers op maniere wat onsigbaar is in 'n lys van gekonfigureerde items. Om die effektiewe volgorde te lees, is die enigste manier om te sien watter reël wen.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Die eerste opdrag lys wat op die masjien gekonfigureer is; die tweede wys wat die kliënt werklik gaan toepas, insluitend inskrywings wat van elders gekom het. As die effektiewe uitset bestuurde naamruimtes bevat, is die eienaar van daardie beleid die regte plek om die verandering te versoek, nie die plaaslike reëllys nie. Albei opdragte lees net toestand, so om hulle te hardloop voordat iemand oor die verandering saamstem, kos niks.

Een reël per naamruimte, hou die objek

Noudat die effektiewe toestand verstaan word, skep een reël per naamruimte en bewaar die objek wat elke opdrag terugstuur. Vertoonname is etikette vir mense, en die unieke identifiseerder in die teruggestuurde objek is daarna die betroubare teiken vir verwydering. Skryf albei identifiseerders in dieselfde veranderingsnota wat die naamruimtes en oplossers vaslê, want die sessie wat hulle geskep het, sal nie die sessie wees wat opruim nie.

$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

Die voorste punt dui 'n agtervoegsel-passing aan, so die reël dek app.svc.internal.example en enigiets anders daaronder. Die twee adresse hier behoort aan hierdie laboratorium se eie roeteringsplan; 'n reël skep nie 'n sone nie, installeer nie 'n roete nie en magtig nie die toepassing wat uiteindelik konek nie, en die verwysing na Add-DnsClientNrptRule dokumenteer presies watter parameters wat doen.

Let op wat hierdie opdragte nie doen nie: hulle is masjienwyd, hulle is nie tot 'n VPN-sessie beperk nie, en hulle oorleef die sluiting van die venster. 'n Laboratorium wat dit vergeet, laat beleid agter nadat die tonnel weg is.

Bewys dat die kliënt die bediener gekies het

Om 'n spesifieke bediener te vra of hy 'n naam ken, bewys dat die bediener kan antwoord, wat nie dieselfde bewering is as dat die kliënt daardie bediener kies nie. Die toets wat saak maak, los 'n werklike naam op deur die gewone kliëntpad en bevestig dan watter oplosser dit hanteer het, ideaal terwyl die tonnel wat die roete verskaf, op is. As die tonnel af is, wys 'n korrek beperkte reël steeds na 'n onbereikbare bediener, wat 'n roeteringsprobleem eerder as 'n beleidsprobleem is. Toets albei toestande sodat die twee later onderskei kan word.

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

Let op gekaste antwoorde uit die tyd voordat die reëls bestaan het, en let op toepassings wat die stelseloplosser heeltemal omseil met hul eie versleutelde DNS. Soek-agtervoegsels is nog 'n aparte funksie: 'n reël kan 'n oplosser vir 'n volledige naam kies sonder om Windows te leer om 'n kale gasheernaam in daardie naamruimte uit te brei.

Verwyder presies wat jy geskep het

Opruiming is waar 'n laboratorium 'n waarskuwende verhaal word. Om elke reël op die masjien te verwyder is vinnig en verwyder beleid waarop iemand anders staatmaak, so gebruik die identifiseerders wat vasgevang is toe die reëls geskep is, en lees die effektiewe toestand daarna weer om te bevestig dat die masjien teruggekeer het na waar dit begin het. As die sessie wat hulle geskep het weg is, is die veranderingsnota die enigste plek waar die identifiseerders bestaan. Dit is die rede om hulle neer te skryf voordat die eerste opdrag loop, nie daarna nie.

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

Vir 'n ontplooiing eerder as 'n laboratorium maak die leeftydsvraag net soveel saak soos die reël. 'n VPN-profiel kan die naamruimte-reëls dra en kies of hulle voortduur na die verbinding; 'n reël wat voortduur terwyl die oplosser onbereikbaar is, laat kliënte 'n dooie bediener verkies, en 'n verbinding-beperkte reël verdwyn wanneer die tonnel dit doen. Besluit watter van daardie gedrag die diens nodig het, merk wie die reël besit, en laat die verdeling van gesag gedokumenteer langs die profiel eerder as in iemand se geheue van 'n laboratorium.