Два DNS сервера на једном адаптеру не деле именске просторе

Навођење два резолвера на једном адаптеру изгледа као начин да се један домен пошаље на један сервер, а други домен на други, и ништа у листи резолвера не ради тако. Windows решава по имену, а одлука који сервер питати долази из објеката политике, а не из уређене листе адреса. Ментални модел који треба заменити је ред: не постоји први сервер за домен A и други сервер за домен B. Постоји скуп правила за сваки именски простор који експлицитно именује сервере, и када та правила постоје, листа адаптера престаје да буде занимљива.

Мит: две адресе деле два домена

Уверење опстаје јер случајно функционише када један сервер одговара на све, а други је само резерва. Клијент пита први сервер, тај сервер прослеђује или извршава рекурзију, и одговор стиже; нико не примећује који је резолвер заправо држао зону. Илузија се руши у тренутку када два именска простора живе у одвојеним приватним зонама без прослеђивања између њих, јер први сервер тада ауторитативно одговара да име не постоји. Негативан одговор првог сервера не покреће резерву, јер је клијент добио коначан одговор, а не квар.

Уређена листа нема појам домена, па не може да изрази намеру. Оно чиме листа заиста управља јесте који се сервер пита први и који се покушава други, и оба одговора једнако важе за свако име.

Шта Windows заиста користи за избор

Табела политике превођења имена усклађује име са конфигурисаним именским просторима и бира сервере и опције за то поклапање. Правила се могу конфигурисати локално, доставити групном политиком или дати VPN профилом, а ефективна политика је комбинација, а не једна листа. Зато је прва дијагностика увек ефективно стање: правило створено локално које губи од управљане политике ствара лабораторију која се понаша сасвим другачије него што њена конфигурација сугерише. Правила се поклапају и по специфичности, па широк запис именског простора може да засени уски на начине који су невидљиви у листи конфигурисаних ставки. Читање ефективног редоследа једини је начин да се види које правило побеђује.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Прва команда набраја шта је конфигурисано на машини; друга показује шта ће клијент заиста применити, укључујући записе који су дошли однекуд другде. Ако ефективни излаз садржи управљане именске просторе, власник те политике је право место за захтев за промену, а не локална листа правила. Обе команде само читају стање, па њихово извршавање пре него што се неко сложи са променом ништа не кошта.

Једно правило по именском простору, сачувајте објекат

Када је ефективно стање схваћено, направите једно правило по именском простору и сачувајте објекат који враћа свака команда. Приказана имена су ознаке за људе, а јединствени идентификатор у враћеном објекту је потом поуздана мета за брисање. Упишите оба идентификатора у исту белешку о промени која евидентира именске просторе и резолвере, јер сесија која их је створила неће бити сесија која чисти.

$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

Почетна тачка означава поклапање суфикса, па правило покрива app.svc.internal.example и све остало испод. Две адресе овде припадају сопственом плану рутирања ове лабораторије; правило не ствара зону, не инсталира руту и не даје овлашћење апликацији која се на крају повезује, и референца за Add-DnsClientNrptRule прецизно документује који параметар шта ради.

Обратите пажњу шта ове команде не раде: оне су за целу машину, нису ограничене на VPN сесију, и преживљавају затварање прозора. Лабораторија која то заборави оставља политику за собом након што тунел нестане.

Докажите да је клијент изабрао сервер

Питање конкретног сервера да ли зна име доказује да сервер може да одговори, што није иста тврдња као да је клијент изабрао тај сервер. Тест који је важан решава стварно име уобичајеним путем клијента и затим потврђује који је резолвер то обрадио, идеално док је тунел који даје руту подигнут. Ако је тунел спуштен, исправно ограничено правило и даље показује на недоступан сервер, а то је проблем рутирања, а не политике. Тестирајте оба стања да би се касније могла разликовати.

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

Пазите на кеширане одговоре из периода пре него што су правила постојала и на апликације које потпуно заобилазе системски резолвер својим шифрованим DNS-ом. Суфикси за претрагу су још једна одвојена функција: правило може да изабере резолвер за пуно име без тога да научи Windows да прошири голи назив домаћина у тај именски простор.

Уклоните тачно оно што сте направили

Чишћење је место где лабораторија постаје поучна прича. Брисање сваког правила на машини је брзо и уклања политику на коју се неко други ослања, зато користите идентификаторе забележене при стварању правила и затим поново прочитајте ефективно стање да потврдите да се машина вратила тамо где је почела. Ако сесија која их је створила више не постоји, белешка о промени је једино место где идентификатори постоје. Зато се они записују пре извршавања прве команде, а не после.

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

За распоређивање, а не лабораторију, питање животног века једнако је важно као правило. VPN профил може да носи правила именских простора и да изабере да ли она остају после везе; правило које остаје док је резолвер недоступан оставља клијенте да преферирају мртав сервер, а правило ограничено на везу нестаје са тунелом. Одлучите које од тих понашања је потребно сервису, означите чије је правило и оставите поделу овлашћења документовану поред профила, а не у нечијем сећању на лабораторију.