Dva strežnika DNS na enem vmesniku ne delita imenskih prostorov
Navedba dveh razreševalnikov na enem vmesniku ne daje vsaki domeni lastne pristojnosti. Zgradite dve omejeni pravili, preizkusite izbiro in odstranite natanko ti dve.
Navedba dveh razreševalnikov na enem vmesniku je videti kot način pošiljanja ene domene na en strežnik in druge domene na drugega, in nič na seznamu razreševalnikov ne deluje tako. Windows razrešuje po imenu, odločitev, katerega strežnika vprašati, pa prihaja iz objektov pravilnika in ne iz urejenega seznama naslovov. Miselni model, ki ga je treba zamenjati, je čakalna vrsta: ni prvega strežnika za domeno A in drugega strežnika za domeno B. Obstaja nabor pravil za vsak imenski prostor, ki strežnike izrecno poimenuje, in ko ta pravila obstajajo, seznam vmesnika preneha biti zanimiv.
Mit: dva naslova delita dve domeni
Prepričanje preživi, ker po naključju deluje, ko en strežnik odgovori na vse, drugi pa je le rezerva. Odjemalec vpraša prvi strežnik, ta posreduje ali izvede rekurzijo, in odgovor prispe; nihče ne opazi, kateri razreševalnik je zares imel območje. Iluzija se zlomi v trenutku, ko oba imenska prostora živita v ločenih zasebnih območjih brez posredovanja med njima, ker prvi strežnik takrat avtoritativno odgovori, da ime ne obstaja. Negativen odgovor prvega strežnika ne sproži rezerve, saj je odjemalec prejel dokončen odgovor in ne napake.
Urejen seznam ne pozna pojma domene, zato ne more izraziti namere. Seznam v resnici nadzira, kateri strežnik je vprašan prvi in kateri poskušen drugi, in oba odgovora enako veljata za vsako ime.
Kaj Windows v resnici uporablja za izbiro
Tabela pravilnika razreševanja imen uskladi ime s konfiguriranimi imenskimi prostori in izbere strežnike ter možnosti za to ujemanje. Pravila je mogoče konfigurirati lokalno, jih dostaviti s skupinskim pravilnikom ali zagotoviti s profilom VPN, dejanski pravilnik pa je kombinacija in ne en seznam. Zato je prva diagnostika vedno dejansko stanje: lokalno ustvarjeno pravilo, ki izgubi proti upravljanemu pravilniku, ustvari laboratorij, ki se obnaša povsem drugače, kot nakazuje njegova konfiguracija. Pravila se ujemajo tudi po specifičnosti, zato lahko širok vnos imenskega prostora zasenči ozek na načine, ki niso vidni na seznamu konfiguriranih elementov. Branje dejanskega vrstnega reda je edini način, da vidimo, katero pravilo zmaga.
Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective
Prvi ukaz navede, kaj je konfigurirano na napravi; drugi pokaže, kaj bo odjemalec dejansko uporabil, vključno z vnosi, ki so prišli od drugod. Če dejanski izpis vsebuje upravljane imenske prostore, je lastnik tega pravilnika pravo mesto za zahtevo po spremembi, ne pa lokalni seznam pravil. Oba ukaza le bereta stanje, zato njuna izvedba, preden se kdo strinja s spremembo, nič ne stane.
Eno pravilo na imenski prostor, objekt shranite
Ko je dejansko stanje razumljeno, ustvarite eno pravilo na imenski prostor in shranite objekt, ki ga vrne vsak ukaz. Prikazana imena so oznake za ljudi, edinstveni identifikator v vrnjenem objektu pa je pozneje zanesljiv cilj za brisanje. Oba identifikatorja zapišite v isto opombo o spremembi, ki beleži imenske prostore in razreševalnike, ker seja, ki jih je ustvarila, ne bo seja, ki počisti.
$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
Vodilna pika označuje ujemanje pripone, zato pravilo pokriva app.svc.internal.example in vse pod njim. Dva naslova tukaj pripadata lastnemu načrtu usmerjanja tega laboratorija; pravilo ne ustvari območja, ne namesti poti in ne pooblasti aplikacije, ki se na koncu poveže, in referenca Add-DnsClientNrptRule natančno dokumentira, kateri parameter kaj počne.
Bodite pozorni, česa ti ukazi ne počnejo: veljajo za celotno napravo, niso omejeni na sejo VPN, in preživijo zaprtje okna. Laboratorij, ki to pozabi, za seboj pusti pravilnik, ko tunela ni več.
Dokažite, da je odjemalec izbral strežnik
Vprašanje določenemu strežniku, ali pozna ime, dokazuje, da strežnik lahko odgovori, kar ni ista trditev kot to, da je odjemalec izbral ta strežnik. Preizkus, ki šteje, razreši resnično ime po običajni poti odjemalca in nato potrdi, kateri razreševalnik ga je obdelal, idealno medtem ko je tunel, ki zagotavlja pot, vzpostavljen. Če je tunel spuščen, pravilno omejeno pravilo še vedno kaže na nedosegljiv strežnik, in to je težava usmerjanja, ne pravilnika. Preizkusite obe stanji, da ju je mogoče pozneje ločiti.
Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile
Pazite na odgovore v predpomnilniku iz obdobja pred nastankom pravil in na aplikacije, ki popolnoma obidejo sistemski razreševalnik z lastnim šifriranim DNS. Iskalne pripone so še ena ločena funkcija: pravilo lahko izbere razreševalnik za polno ime, ne da bi Windows naučilo razširiti golo ime gostitelja v ta imenski prostor.
Odstranite natanko to, kar ste ustvarili
Čiščenje je mesto, kjer laboratorij postane svarilna zgodba. Izbrisati vsako pravilo na napravi je hitro in odstrani pravilnik, na katerega se zanaša nekdo drug, zato uporabite identifikatorje, zajete ob ustvarjanju pravil, in nato znova preberite dejansko stanje, da potrdite, da se je naprava vrnila tja, kjer je začela. Če seje, ki jih je ustvarila, ni več, je opomba o spremembi edino mesto, kjer identifikatorji obstajajo. Zato jih zapišemo pred izvedbo prvega ukaza, ne po njej.
Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective
Pri uvajanju in ne laboratoriju je vprašanje življenjske dobe prav tako pomembno kot pravilo. Profil VPN lahko nosi pravila imenskih prostorov in izbere, ali ostanejo tudi po povezavi; pravilo, ki ostane, medtem ko je razreševalnik nedosegljiv, pusti odjemalce, da raje izberejo mrtvi strežnik, pravilo, omejeno na povezavo, pa izgine skupaj s tunelom. Odločite, katero od teh vedenj storitev potrebuje, označite, kdo je lastnik pravila, in pustite razdelitev pristojnosti dokumentirano ob profilu in ne v nekom spominu na laboratorij.