Ваш VPN предлагает три DNS-сервера: какой из них отвечает?

Откройте страницу настроек после подключения, и вы увидите три адреса DNS; вопрос аудита в том, какой из них обработал ваш последний запрос. Одно число ничего не решает, потому что клиентская рассылка, физический интерфейс и политика для отдельных доменов пишут в одно и то же представление. У этих записей разные области действия, и именно область, а не позиция, определяет, кто отвечает. Начните с разделения источников, затем проверьте тот, которому принадлежит важное вам имя.

Почему список длиннее вашего профиля

VPN-клиент рассылает адреса распознавателя для туннельного подключения, а операционная система держит их рядом с тем, что уже было у физического интерфейса. Маршрутизатор, корпоративная аренда DHCP, второй VPN и политика для отдельных доменов добавляют каждый свою запись. Поэтому три адреса на странице могут означать три области действия, а не три кандидата на одну задачу. Читать число как доказательство утечки — первая ошибка этого аудита.

В пределах одного интерфейса клиент действительно пробует свои серверы по порядку, так что упорядоченный список не бессмыслен. Очередью не является объединённое представление, где записи профиля, физического подключения и правил для отдельных доменов стоят рядом без единого ранжирования. Это различие определяет, что вы проверяете: порядок объясняет поведение внутри одной области, а область объясняет всё остальное.

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

Что показывает каждая из трёх проверок

Каждый источник оставляет след в другом месте, и ни одна команда не показывает все. Вот сопоставление, которое стоит держать рядом со страницей настроек:

В системе с systemd-resolved авторитетна resolvectl status, потому что она сообщает DNS по каждому подключению вместе с доменами маршрутизации. macOS отвечает через scutil --dns, которая перечисляет распознаватели с областью в порядке их проверки. Windows делит две половины: Get-DnsClientServerAddress для серверов по интерфейсам и Get-DnsClientNrptPolicy для правил суффиксов. Запустите команду, которая относится к фактически используемому распознавателю, потому что на машине со средой контейнеров и настольным распознавателем может быть установлено больше одного.

Резервный распознаватель, который не может ответить за вашу зону

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

Split DNS существует, чтобы этого не допустить: суффиксы компании идут к распознавателю, владеющему зоной, а публичные имена остаются на стандартном пути. Замысел надёжен, и он зависит от полноты списка суффиксов. Microsoft документирует политику распознавателя для каждого суффикса, которая управляет этим в Windows, и та же идея проявляется как домены маршрутизации в systemd-resolved и как распознаватели с областью в macOS.

Сравните зоны, за которые резерв вправе отвечать, с суффиксами в политике. Это сравнение находит пробел до того, как пользователь сообщит, что один внутренний сайт перестал разрешаться после изменения туннеля.

Спрашивайте через политику, а не в обход неё

Спрашивайте через распознаватель операционной системы, потому что прямой запрос к серверу обходит политику и сообщает только то, что сказал бы этот сервер. Разница между двумя ответами и есть вся суть:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

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

Затем проверьте путь отказа, потому что резерв, который никто не тестировал, — это допущение. Сделайте предпочитаемый распознаватель чёрной дырой для одного запроса и посмотрите, какой адрес вернётся:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

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

Решите: оставить, ограничить или удалить

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

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