Захоплення 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 від наступного за нею з’єднання зі службою: розв’язана приватна адреса все ще потребує маршруту й дозволу застосунку.