Dalawang DNS server sa isang adapter ay hindi naghahati ng mga namespace

Ang paglilista ng dalawang resolver sa isang adapter ay mukhang paraan upang ipadala ang isang domain sa isang server at ang isa pang domain sa kabila, at wala sa listahan ng resolver ang gumagana nang ganoon. Nagre-resolve ang Windows ayon sa pangalan, at ang desisyon kung aling server ang tatanungin ay nagmumula sa mga bagay ng patakaran at hindi sa isang nakaayos na listahan ng address. Ang modelong pangkaisipan na dapat palitan ay ang pila: walang unang server para sa domain A at ikalawang server para sa domain B. May isang set ng mga patakaran para sa bawat namespace na tahasang nagbibigay ng pangalan ng mga server, at kapag umiiral na ang mga patakarang iyon, hindi na kawili-wili ang listahan ng adapter.

Ang mito: dalawang address ang naghahati ng dalawang domain

Nabubuhay ang paniniwalang ito dahil nagkataong gumagana ito kapag isang server ang sumasagot sa lahat at ang pangalawa ay pang-aliw lang. Nagtatanong ang kliyente sa unang server, nagpapasa o nagre-recurse ang server na iyon, at dumarating ang sagot; walang nakakapansin kung aling resolver ang talagang may hawak ng zone. Nasasira ang ilusyon sa sandaling manirahan ang dalawang namespace sa magkahiwalay na pribadong zone na walang pagpapasa sa pagitan nila, dahil sumasagot na nang may awtoridad ang unang server na wala ang pangalan. Ang negatibong sagot mula sa unang server ay hindi nagpapagana ng pang-aliw, dahil nakatanggap ang kliyente ng tiyak na sagot at hindi ng pagkabigo.

Ang nakaayos na listahan ay walang konsepto ng domain, kaya hindi nito maipahayag ang layunin. Ang talagang kinokontrol ng listahan ay kung aling server ang tatanungin muna at alin ang susubukan pangalawa, at ang parehong sagot ay pantay na naaangkop sa bawat pangalan.

Ano ang aktwal na ginagamit ng Windows upang pumili

Ang talahanayan ng Patakaran sa Paglutas ng Pangalan ay nagtutugma ng pangalan sa mga naka-configure na namespace at pumipili ng mga server at opsyon para sa tugmang iyon. Maaaring i-configure ang mga patakaran nang lokal, ihatid sa pamamagitan ng Group Policy, o ibigay ng isang profile ng VPN, at ang epektibong patakaran ay isang kumbinasyon at hindi isang listahan. Kaya ang unang diagnostic ay palaging epektibong estado: ang isang patakarang ginawa nang lokal na natatalo sa isang pinamamahalaang patakaran ay gumagawa ng laboratoryo na kumikilos nang ibang-iba sa ipinahihiwatig ng configuration nito. Ang mga patakaran ay tinutugma rin ayon sa pagiging tiyak, kaya ang isang malawak na entry ng namespace ay maaaring magtakip sa isang makitid sa mga paraang hindi nakikita sa isang listahan ng mga naka-configure na item. Ang pagbasa ng epektibong pagkakasunod-sunod ang tanging paraan upang makita kung aling patakaran ang nananalo.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Inililista ng unang utos kung ano ang naka-configure sa makina; ipinapakita ng pangalawa kung ano ang aktwal na ilalapat ng kliyente, kasama ang mga entry na nagmula sa ibang lugar. Kung ang epektibong output ay may mga pinamamahalaang namespace, ang may-ari ng patakarang iyon ang tamang lugar upang hilingin ang pagbabago, hindi ang lokal na listahan ng patakaran. Pareho lang bumasa ng estado ang dalawang utos, kaya walang gastos ang pagpapatakbo sa kanila bago sumang-ayon ang sinuman sa pagbabago.

Isang patakaran bawat namespace, itago ang bagay

Kapag naunawaan na ang epektibong estado, gumawa ng isang patakaran bawat namespace at itago ang bagay na ibinabalik ng bawat utos. Ang mga pangalan ng display ay mga label para sa mga tao, at ang natatanging identifier sa ibinalik na bagay ay ang mapagkakatiwalaang target ng pagtanggal pagkatapos. Isulat ang parehong identifier sa parehong tala ng pagbabago na nagtatala ng mga namespace at resolver, dahil ang sesyon na lumikha sa kanila ay hindi ang sesyong maglilinis.

$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

Ang unang tuldok ay nagpapahiwatig ng tugma ng suffix, kaya saklaw ng patakaran ang app.svc.internal.example at anumang iba pa sa ilalim nito. Ang dalawang address dito ay pag-aari ng sariling plano sa pagruruta ng laboratoryong ito; ang isang patakaran ay hindi gumagawa ng zone, hindi nag-i-install ng ruta at hindi nagbibigay ng pahintulot sa application na tuluyang kumokonekta, at ang sanggunian ng Add-DnsClientNrptRule ay dokumentadong eksakto kung aling parameter ang gumagawa ng ano.

Pansinin ang hindi ginagawa ng mga utos na ito: ang mga ito ay para sa buong makina, hindi limitado sa isang sesyon ng VPN, at nananatili pagkatapos isara ang bintana. Ang isang laboratoryo na nakakalimot nito ay nag-iiwan ng patakaran pagkatapos mawala ang tunel.

Patunayan na pinili ng kliyente ang server

Ang pagtatanong sa isang partikular na server kung kilala nito ang isang pangalan ay nagpapatunay na makakasagot ang server, na hindi kapareho ng pag-aangkin na pinili ng kliyente ang server na iyon. Ang pagsubok na mahalaga ay nagre-resolve ng tunay na pangalan sa karaniwang landas ng kliyente at pagkatapos ay kinukumpirma kung aling resolver ang humawak nito, pinakamainam habang nakabukas ang tunel na nagbibigay ng ruta. Kung sarado ang tunel, ang isang wastong saklaw na patakaran ay tumuturo pa rin sa isang server na hindi maabot, at iyon ay problema sa pagruruta at hindi sa patakaran. Subukan ang parehong estado upang maipakilala ang mga ito sa ibang pagkakataon.

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

Magbantay sa mga naka-cache na sagot mula sa panahon bago umiral ang mga patakaran, at magbantay sa mga application na ganap na lumalampas sa resolver ng system gamit ang sarili nilang naka-encrypt na DNS. Ang mga suffix ng paghahanap ay isa pang hiwalay na tampok: ang isang patakaran ay maaaring pumili ng resolver para sa isang buong pangalan nang hindi nagtuturo sa Windows na palawakin ang hubad na hostname sa namespace na iyon.

Alisin ang eksaktong ginawa mo

Ang paglilinis ang lugar kung saan nagiging kuwentong babala ang isang laboratoryo. Ang pagtanggal sa bawat patakaran sa makina ay mabilis at nag-aalis ng patakarang umaasa ang ibang tao, kaya gamitin ang mga identifier na nakuha noong ginawa ang mga patakaran, at muling basahin ang epektibong estado pagkatapos upang kumpirmahin na bumalik ang makina sa pinagsimulan nito. Kung wala na ang sesyong lumikha sa kanila, ang tala ng pagbabago ang tanging lugar kung saan umiiral ang mga identifier. Iyon ang dahilan upang isulat ang mga ito bago tumakbo ang unang utos, at hindi pagkatapos.

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

Para sa isang deployment at hindi isang laboratoryo, ang tanong ng tagal ng buhay ay kasinghalaga ng patakaran. Ang isang profile ng VPN ay maaaring magdala ng mga patakaran ng namespace at pumili kung mananatili ang mga ito pagkatapos ng koneksyon; ang isang patakarang nananatili habang hindi maabot ang resolver ay nag-iiwan sa mga kliyente na mas gusto ang patay na server, at ang isang patakarang nakasaklaw sa koneksyon ay nawawala kapag nawala ang tunel. Magpasya kung alin sa mga pag-uugaling ito ang kailangan ng serbisyo, markahan kung sino ang may-ari ng patakaran, at iwanan ang paghahati ng awtoridad na dokumentado sa tabi ng profile at hindi sa alaala ng sinuman tungkol sa isang laboratoryo.