Два 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 профилот може да ги носи правилата за именски простори и да избере дали тие остануваат по врската; правило што останува додека решавачот е недостапен ги остава клиентите да претпочитаат мртов сервер, а правило ограничено на врската исчезнува со тунелот. Одлучете кое од тие однесувања му е потребно на сервисот, означете чие е правилото и оставете поделбата на овластувања документирана до профилот, а не во нечие сеќавање на лабораторија.