Два 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 може нести правила простору імен і вибирати, чи зберігаються вони після підключення; правило, яке зберігається, доки резолвер недоступний, змушує клієнтів віддавати перевагу мертвому серверу, а правило, обмежене підключенням, зникає разом із тунелем. Вирішіть, яка з цих поведінок потрібна службі, позначте, кому належить правило, і залиште поділ повноважень задокументованим поруч із профілем, а не в чиїйсь пам'яті про лабораторію.