Két DNS-kiszolgáló egy adapteren nem osztja szét a névtereket

Két feloldó listázása egy adapteren úgy tűnik, mintha az egyik tartományt az egyik kiszolgálóhoz, a másikat a másikhoz küldenénk, és a feloldólista egyetlen eleme sem működik így. A Windows név szerint old fel, és arról, hogy melyik kiszolgálót kérdezzük, házirend-objektumok döntenek, nem egy rendezett címlista. A lecserélendő mentális modell a sor: nincs első kiszolgáló az A tartományhoz és második kiszolgáló a B tartományhoz. Névterenként van egy szabálykészlet, amely kifejezetten megnevezi a kiszolgálókat, és amint ezek a szabályok léteznek, az adapter listája már nem érdekes.

A mítosz: két cím két tartományt oszt szét

A hit azért marad fenn, mert véletlenül működik, amikor az egyik kiszolgáló mindenre válaszol, a második pedig csak tartalék. Az ügyfél az első kiszolgálót kérdezi, az továbbít vagy rekurzívan kérdez, és a válasz megérkezik; senki nem veszi észre, melyik feloldó birtokolta valójában a zónát. Az illúzió abban a pillanatban törik meg, amikor a két névtér külön privát zónákban él, köztük továbbítás nélkül, mert akkor az első kiszolgáló mérvadóan azt válaszolja, hogy a név nem létezik. Az első kiszolgáló negatív válasza nem indítja be a tartalékot, mert az ügyfél végleges választ kapott, nem hibát.

A rendezett listának nincs tartalomfogalma, ezért nem tudja kifejezni a szándékot. Amit a lista valójában vezérel, az az, hogy melyik kiszolgálót kérdezzük először és melyiket próbáljuk másodszor, és mindkét válasz egyformán vonatkozik minden névre.

Mit használ a Windows valójában a választáshoz

A névfeloldási házirend-tábla egy nevet a beállított névterekhez illeszt, és kiválasztja az adott egyezéshez tartozó kiszolgálókat és beállításokat. A szabályok helyben beállíthatók, csoportházirenddel terjeszthetők vagy VPN-profilból adhatók, és a tényleges házirend nem egyetlen lista, hanem kombináció. Ezért az első diagnózis mindig a tényleges állapot: egy helyben létrehozott szabály, amely alulmarad egy felügyelt házirenddel szemben, olyan labort hoz létre, amely egyáltalán nem úgy viselkedik, ahogy a konfigurációja sejteti. A szabályok specificitás szerint is illeszkednek, így egy széles névtér-bejegyzés olyan módokon nyomhatja el a szűket, amelyek egy beállított elemekből álló listában láthatatlanok. A tényleges sorrend olvasása az egyetlen módja annak, hogy lássuk, melyik szabály nyer.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Az első parancs felsorolja, mi van beállítva a gépen; a második megmutatja, mit fog az ügyfél valóban alkalmazni, beleértve a máshonnan érkezett bejegyzéseket is. Ha a tényleges kimenet felügyelt névtereket tartalmaz, a változás kérésének helyes helye az adott házirend tulajdonosa, nem a helyi szabálylista. Mindkét parancs csak állapotot olvas, ezért futtatásuk még azelőtt, hogy bárki egyetértene a változással, semmibe nem kerül.

Névterenként egy szabály, őrizze meg az objektumot

Miután a tényleges állapot érthetővé vált, hozzon létre névterenként egy szabályt, és őrizze meg az objektumot, amelyet az egyes parancsok visszaadnak. A megjelenített nevek embereknek szóló címkék, a visszaadott objektumban lévő egyedi azonosító pedig később a megbízható törlési cél. Írja mindkét azonosítót ugyanabba a változásjegyzetbe, amely a névtereket és a feloldókat rögzíti, mert a létrehozó munkamenet nem az a munkamenet lesz, amelyik kitakarít.

$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

A kezdő pont utótag-egyezést jelöl, így a szabály lefedi a app.svc.internal.example nevet és mindent, ami alatta van. A két cím itt ennek a labornak a saját útvonaltervéhez tartozik; egy szabály nem hoz létre zónát, nem telepít útvonalat és nem jogosítja fel az alkalmazást, amely végül csatlakozik, és a Add-DnsClientNrptRule-referencia pontosan dokumentálja, melyik paraméter mit tesz.

Figyelje meg, mit nem tesznek ezek a parancsok: az egész gépre érvényesek, nem korlátozódnak VPN-munkamenetre, és túlélik az ablak bezárását. Az a labor, amely ezt elfelejti, házirendet hagy maga után, amikor az alagút eltűnik.

Bizonyítsa, hogy az ügyfél választotta a kiszolgálót

Ha megkérdezünk egy adott kiszolgálót, hogy ismer-e egy nevet, az bizonyítja, hogy a kiszolgáló tud válaszolni, ami nem ugyanaz az állítás, mint hogy az ügyfél azt a kiszolgálót választotta. A számító teszt a szokásos ügyfélúton old fel egy valódi nevet, majd megerősíti, melyik feloldó kezelte, ideálisan akkor, amikor az útvonalat biztosító alagút áll. Ha az alagút le van zárva, egy helyesen határolt szabály továbbra is elérhetetlen kiszolgálóra mutat, ami útvonalprobléma, nem házirendprobléma. Tesztelje mindkét állapotot, hogy később meg lehessen különböztetni őket.

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

Figyeljen a szabályok létezése előtti időszak gyorsítótárazott válaszaira, és azokra az alkalmazásokra, amelyek saját titkosított DNS-ükkel teljesen megkerülik a rendszerfeloldót. A keresési utótagok egy másik külön szolgáltatás: egy szabály választhat feloldót egy teljes névhez anélkül, hogy megtanítaná a Windowsnak a csupasz gazdagépnév kiterjesztését abba a névtérbe.

Pontosan azt távolítsa el, amit létrehozott

A takarítás az a pont, ahol a labor tanulságos történetté válik. A gépen minden szabály törlése gyors, és olyan házirendet távolít el, amelyre más támaszkodik, ezért használja a szabályok létrehozásakor rögzített azonosítókat, majd olvassa újra a tényleges állapotot, hogy megbizonyosodjon arról, a gép visszatért oda, ahonnan indult. Ha a létrehozó munkamenet már nincs meg, a változásjegyzet az egyetlen hely, ahol az azonosítók léteznek. Ezért kell őket az első parancs futtatása előtt leírni, nem utána.

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

Telepítésnél, nem labornál az élettartam kérdése ugyanolyan fontos, mint a szabály. Egy VPN-profil hordozhatja a névtér-szabályokat, és eldöntheti, hogy azok a kapcsolat után is megmaradnak-e; egy szabály, amely akkor is megmarad, amikor a feloldó elérhetetlen, arra készteti az ügyfeleket, hogy egy halott kiszolgálót részesítsenek előnyben, a kapcsolathoz kötött szabály pedig eltűnik, amikor az alagút is. Döntse el, melyik viselkedésre van szüksége a szolgáltatásnak, jelölje meg, ki tulajdonosa a szabálynak, és hagyja a felhatalmazás felosztását a profil mellett dokumentálva, ne valaki laborral kapcsolatos emlékezetében.