Захват Split-DNS: укажите, где сделано каждое наблюдение

Два человека разбирают одну и ту же проблему Split-DNS и получают разные адреса резолвера. Один использовал инструмент поиска, второй захватил пакеты на адаптере, а третий прочитал собственную диагностику клиента. Никто из них не лжёт, и никто не описывает один и тот же этап. Назвав точку наблюдения, вы превращаете противоречие в карту.

Один поиск, несколько точек наблюдения

Для одного внутреннего имени есть как минимум пять мест, куда смотреть: приложение и API резолвера, которое оно вызывает, действующая политика домена на клиенте, захват на адаптере или фильтре, контролируемая граница шлюза и резолвер, который действительно получает запрос.

Каждое отвечает на свой вопрос, и ни одно само по себе не доказывает, куда ушёл запрос.

Захват на адаптере показывает пакеты, а не намерение. Он не говорит, какой резолвер выбрал клиент, а пустой захват может означать закэшированный ответ или другой API резолвера, а не отброшенный пакет. Считайте каждое наблюдение свидетельством об одном этапе. Затем соберите этапы в путь.

Фильтр клиента стоит между приложением и проводом

VPN-клиент с Split-DNS применяет сопоставление доменов до того, как пакет покинет машину. Имена в туннельном суффиксе идут к внутреннему резолверу; всё остальное идёт к локальному. Фильтр — это политика, и политика может различаться в зависимости от платформы и версии клиента.

Рекомендации Secure Client по Split-DNS от Cisco охватывают сопоставление доменов и фильтр Windows и разделяют то, что видит приложение при использовании родного API резолвера, и то, что видит инструмент вроде nslookup. Именно эти различия и важны.

Начните с действующего профиля и одного обычного запроса приложения. Любой тест, который называет конкретный сервер, — это намеренный обход; объясните его собственной диагностикой клиента и не позволяйте ему стать критерием приёмки.

nslookup идёт другим путём, чем приложение

nslookup строит собственный DNS-запрос и может обойти политику резолвера операционной системы. Это делает его полезным инструментом, чтобы задать конкретному серверу конкретный вопрос, и обманчивым инструментом для проверки того, что испытает приложение.

В Windows таблица политики разрешения имён решает, какой суффикс использует какой сервер. Её чтение показывает политику, которой будет следовать приложение, и часто это и есть недостающий фрагмент.

Прочитайте политику и затем задайте тот же вопрос через обычный резолвер:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Зашифрованные резолверы скрывают запрос, а не соединение

Браузер с собственным резолвером DNS-over-HTTPS — совсем другой случай. Запрос выходит внутри TLS, поэтому захват пакетов показывает соединение с адресом резолвера, но не имя, о котором спрашивают.

Сначала выясните управляемую политику браузера, затем сравните её с поиском через операционную систему. Браузер, которому разрешено выбирать собственный резолвер, может вообще не видеть политику Split-DNS.

Та же осторожность относится к любому клиенту, который поставляет собственный резолвер. Захват, идентифицирующий удалённое соединение, не является доказательством об имени запроса. Если имя нужно, возьмите его из журналов самого резолвера или из диагностики приложения, с учётом применимых правил конфиденциальности.

Сравните с помеченным тестом

Выберите одобренное внутреннее имя для теста, а также публичное имя, не несущее чувствительного смысла. Для каждого запишите время, тип записи, ответ и ожидаемую политику.

Там, где это разрешено, сравните получение запроса резолвером с одним узким наблюдением на клиенте или шлюзе:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Никогда не отправляйте приватные имена несвязанным публичным резолверам только для создания сравнения и редактируйте всё, чем делитесь. Наконец, отделите правильный ответ DNS от следующего за ним подключения к службе: разрешённому приватному адресу по-прежнему нужны маршрут и разрешение приложения.