Două servere DNS pe un singur adaptor nu împart spațiile de nume

Listarea a doi rezolvitori pe un adaptor pare o cale de a trimite un domeniu la un server și alt domeniu la celălalt, și nimic din lista de rezolvitori nu funcționează astfel. Windows rezolvă după nume, iar decizia privind serverul care va fi întrebat vine din obiecte de politică și nu dintr-o listă ordonată de adrese. Modelul mental care trebuie înlocuit este coada: nu există un prim server pentru domeniul A și un al doilea server pentru domeniul B. Există un set de reguli pentru fiecare spațiu de nume care numește serverele în mod explicit, iar odată ce aceste reguli există, lista adaptorului încetează să mai fie interesantă.

Mitul: două adrese împart două domenii

Convingerea supraviețuiește pentru că funcționează din întâmplare atunci când un server răspunde la tot, iar al doilea este doar o rezervă. Un client întreabă primul server, acel server redirecționează sau face recursiune, iar răspunsul sosește; nimeni nu observă care rezolvitor deținea de fapt zona. Iluzia se sparge în momentul în care cele două spații de nume trăiesc în zone private separate, fără redirecționare între ele, pentru că atunci primul server răspunde cu autoritate că numele nu există. Un răspuns negativ de la primul server nu declanșează rezerva, întrucât clientul a primit un răspuns definitiv și nu o eroare.

O listă ordonată nu are noțiunea de domeniu, așa că nu poate exprima intenția. Ceea ce controlează lista de fapt este care server este întrebat primul și care este încercat al doilea, iar ambele răspunsuri se aplică în mod egal fiecărui nume.

Ce folosește Windows de fapt pentru a alege

Tabelul de politică pentru rezolvarea numelor potrivește un nume cu spațiile de nume configurate și selectează serverele și opțiunile pentru acea potrivire. Regulile pot fi configurate local, livrate prin politică de grup sau furnizate de un profil VPN, iar politica efectivă este o combinație și nu o singură listă. De aceea primul diagnostic este întotdeauna starea efectivă: o regulă creată local care pierde în fața unei politici administrate produce un laborator care se comportă complet diferit față de ceea ce sugerează configurația sa. Regulile sunt potrivite și după specificitate, așa că o intrare largă de spațiu de nume poate umbri una îngustă în moduri invizibile într-o listă de elemente configurate. Citirea ordinii efective este singura cale de a vedea care regulă câștigă.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Prima comandă enumeră ce este configurat pe mașină; a doua arată ce va aplica de fapt clientul, inclusiv intrările care au venit din altă parte. Dacă ieșirea efectivă conține spații de nume administrate, proprietarul acelei politici este locul corect pentru a solicita schimbarea, nu lista locală de reguli. Ambele comenzi doar citesc stare, așa că rularea lor înainte ca cineva să fie de acord cu schimbarea nu costă nimic.

O regulă pentru fiecare spațiu de nume, păstrați obiectul

După ce starea efectivă este înțeleasă, creați o regulă pentru fiecare spațiu de nume și păstrați obiectul pe care îl returnează fiecare comandă. Numele de afișare sunt etichete pentru oameni, iar identificatorul unic din obiectul returnat este apoi ținta fiabilă de ștergere. Scrieți ambii identificatori în aceeași notă de modificare care înregistrează spațiile de nume și rezolvitorii, pentru că sesiunea care le-a creat nu va fi sesiunea care curăță.

$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

Punctul inițial marchează o potrivire de sufix, așa că regula acoperă app.svc.internal.example și orice altceva de sub el. Cele două adrese de aici aparțin planului de rutare propriu al acestui laborator; o regulă nu creează o zonă, nu instalează o rută și nu autorizează aplicația care se conectează în final, iar referința pentru Add-DnsClientNrptRule documentează exact ce face fiecare parametru.

Observați ce nu fac aceste comenzi: sunt valabile pentru întreaga mașină, nu sunt limitate la o sesiune VPN, și supraviețuiesc închiderii ferestrei. Un laborator care uită acest lucru lasă politică în urmă după ce tunelul dispare.

Dovediți că clientul a ales serverul

A întreba un server anume dacă cunoaște un nume dovedește că serverul poate răspunde, ceea ce nu este aceeași afirmație cu faptul că clientul a ales acel server. Testul care contează rezolvă un nume real prin calea obișnuită a clientului și apoi confirmă care rezolvitor l-a tratat, ideal în timp ce tunelul care furnizează ruta este activ. Dacă tunelul este oprit, o regulă corect delimitată indică în continuare un server inaccesibil, iar aceasta este o problemă de rutare și nu de politică. Testați ambele stări pentru ca ele să poată fi distinse mai târziu.

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

Fiți atenți la răspunsurile din cache din perioada de dinainte de existența regulilor și la aplicațiile care ocolesc complet rezolvitorul sistemului cu propriul DNS criptat. Sufixele de căutare sunt o altă funcție separată: o regulă poate alege un rezolvitor pentru un nume complet fără a învăța Windows să extindă un nume de gazdă simplu în acel spațiu de nume.

Eliminați exact ceea ce ați creat

Curățarea este locul unde un laborator devine o poveste de avertizare. Ștergerea fiecărei reguli de pe mașină este rapidă și elimină politică de care depinde altcineva, așa că folosiți identificatorii capturați la crearea regulilor și recitiți starea efectivă după aceea pentru a confirma că mașina a revenit unde a început. Dacă sesiunea care le-a creat nu mai există, nota de modificare este singurul loc unde identificatorii există. Acesta este motivul pentru care sunt scrise înainte de rularea primei comenzi, și nu după.

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

Pentru un desfășurare și nu un laborator, întrebarea duratei de viață contează tot atât cât regula. Un profil VPN poate transporta regulile de spațiu de nume și poate alege dacă ele persistă după conexiune; o regulă care persistă în timp ce rezolvitorul este inaccesibil lasă clienții să prefere un server mort, iar o regulă limitată la conexiune dispare când o face tunelul. Decideți care dintre aceste comportamente este necesar serviciului, marcați cine deține regula și lăsați împărțirea autorității documentată lângă profil și nu în memoria cuiva despre un laborator.