Kaks DNS-serverit ühel adapteril ei jaga nimeruume

Kahe resolveri loetlemine ühel adapteril näib viisina saata üks domeen ühte serverisse ja teine domeen teise, ning miski resolverite loendis ei tööta nii. Windows lahendab nime järgi ja otsus, millist serverit küsida, tuleb poliitikaobjektidest, mitte järjestatud aadressiloendist. Vaimne mudel, mille tuleb asendada, on järjekord: domeeni A jaoks pole esimest serverit ja domeeni B jaoks teist serverit. On nimeruumi kohta reeglistik, mis nimetab serverid selgesõnaliselt, ja kui need reeglid on olemas, ei paketa adapteri loend enam huvi.

Müüt: kaks aadressi jagavad kahte domeeni

Uskumus püsib, sest see töötab juhuslikult siis, kui üks server vastab kõigele ja teine on vaid varuvariant. Klient küsib esimest serverit, see server edastab või rekursioonib ja vastus saabub; keegi ei märka, milline resolver tsooni tegelikult hoidis. Illusioon puruneb hetkel, mil kaks nimeruumi elavad eraldi privaatsetes tsoonides ilma nende vahelise edastuseta, sest siis vastab esimene server autoriteetselt, et nime ei ole olemas. Esimese serveri eitav vastus ei käivita varuvarianti, kuna klient sai lõpliku vastuse, mitte tõrke.

Järjestatud loendil pole domeeni mõistet, seega ei saa see kavatsust väljendada. Loend kontrollib tegelikult seda, millist serverit küsitakse esimesena ja millist proovitakse teisena, ning mõlemad vastused kehtivad iga nime kohta võrdselt.

Mida Windows valimiseks tegelikult kasutab

Nimelahenduse poliitikatabel vastab nime konfigureeritud nimeruumidele ja valib selle vastenduse jaoks serverid ja valikud. Reegleid saab konfigureerida kohapeal, edastada rühmapoliitikaga või anda VPN-profiiliga, ning kehtiv poliitika on kombinatsioon, mitte üksik loend. Seetõttu on esimene diagnostika alati kehtiv olek: kohapeal loodud reegel, mis kaotab hallatud poliitikale, toodab labori, mis ei käitu üldse nii, nagu selle konfiguratsioon vihjab. Reegleid vastendatakse ka spetsiifilisuse järgi, nii et lai nimeruumi kirje võib kitsa varjutada viisil, mis pole konfigureeritud üksuste loendis nähtav. Kehtiva järjekorra lugemine on ainus viis näha, milline reegel võidab.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Esimene käsk loetleb, mis on masinas konfigureeritud; teine näitab, mida klient tegelikult rakendab, sealhulgas mujalt tulnud kirjed. Kui kehtiv väljund sisaldab hallatud nimeruumi, on selle poliitika omanik õige koht muudatuse taotlemiseks, mitte kohalik reegliloend. Mõlemad käsud ainult loevad olekut, seega nende käivitamine enne, kui keegi muudatusega nõustub, ei maksa midagi.

Üks reegel nimeruumi kohta, hoia objekt alles

Kui kehtiv olek on selge, loo üks reegel nimeruumi kohta ja säilita objekt, mille iga käsk tagastab. Kuvatavad nimed on siltideks inimestele ja tagastatud objekti unikaalne identifikaator on hiljem usaldusväärne kustutamise sihtmärk. Kirjuta mõlemad identifikaatorid samasse muudatusmärkesse, mis fikseerib nimeruumid ja resolverid, sest sessioon, mis need lõi, ei ole see sessioon, mis koristab.

$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

Juhtiv punkt tähistab sufiksi vastet, seega reegel katab app.svc.internal.example ja kõike muud selle all. Kaks aadressi siin kuuluvad selle labori enda marsruutimisplaani; reegel ei loo tsooni, ei paigalda marsruuti ega volita rakendust, mis lõpuks ühendub, ja Add-DnsClientNrptRule viide dokumenteerib täpselt, milline parameeter mida teeb.

Pange tähele, mida need käsud ei tee: need on kogu masina ulatuses, mitte piiratud VPN-sessiooniga, ja need jäävad püsima ka pärast akna sulgemist. Labor, mis selle unustab, jätab poliitika maha, kui tunnel on kadunud.

Tõesta, et klient valis serveri

Konkreetselt serverilt küsimine, kas see teab nime, tõestab, et server suudab vastata, mis ei ole sama väide kui see, et klient valis selle serveri. Test, millel on tähtsust, lahendab päris nime kliendi tavapärasel teel ja kinnitab seejärel, milline resolver sellega tegeles, ideaalis siis, kui marsruuti andev tunnel on üleval. Kui tunnel on maas, osutab õigesti piiratud reegel ikkagi kättesaamatule serverile, mis on marsruutimise, mitte poliitika probleem. Testi mõlemat olekut, et neid hiljem eristada saaks.

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

Jälgi vahemällu salvestatud vastuseid ajavahemikust enne reeglite olemasolu ja jälgi rakendusi, mis mööduvad süsteemi resolverist täielikult oma krüpteeritud DNS-iga. Otsingusufiksid on veel üks eraldi funktsioon: reegel saab valida resolveri täisnime jaoks, õpetamata Windowsile paljast hostinime sellesse nimeruumi laiendada.

Eemalda täpselt see, mille lõid

Koristamine on koht, kus laborist saab hoiatav lugu. Kõigi masina reeglite kustutamine on kiire ja eemaldab poliitika, millest keegi teine sõltub, seega kasuta reeglite loomisel jäädvustatud identifikaatoreid ja loe seejärel kehtiv olek uuesti, et kinnitada, et masin naasis sinna, kust alustas. Kui sessioon, mis need lõi, on kadunud, on muudatusmärge ainus koht, kus identifikaatorid eksisteerivad. Seepärast kirjutatakse need üles enne esimese käsu käivitamist, mitte pärast.

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

Juurutuse, mitte labori puhul loeb eluea küsimus sama palju kui reegel. VPN-profiil võib kanda nimeruumi reegleid ja valida, kas need püsivad ka pärast ühendust; reegel, mis püsib, kui resolver on kättesaamatu, jätab kliendid eelistama surnud serverit, ja ühendusega piiratud reegel kaob koos tunneliga. Otsusta, millist neist käitumistest teenus vajab, märgi, kellele reegel kuulub, ja jäta volituste jaotus dokumenteerituks profiili kõrvale, mitte kellegi mälestusse laborist.