Два 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 может нести правила пространства имён и выбирать, сохраняются ли они после подключения; правило, которое сохраняется, пока резолвер недоступен, заставляет клиентов предпочитать мёртвый сервер, а правило, ограниченное подключением, исчезает вместе с туннелем. Решите, какое из этих поведений нужно службе, отметьте, кому принадлежит правило, и оставьте разделение полномочий задокументированным рядом с профилем, а не в чьей-то памяти о лаборатории.