VPN исправил DNS или просто повторно использовал кэшированный ответ?

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

Сравните, что на самом деле проверял каждый тест, прежде чем приписывать успех изменению.

Загрузка страницы — это не запрос

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

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

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

Посчитайте кэши, прежде чем делать вывод

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

Отрицательные ответы тоже кэшируются. Имя, о котором сообщили как об отсутствующем, может остаться отсутствующим после исправления сети, и это читается как сломанный туннель, хотя на деле это ещё не истёкший TTL. Спецификация DNS описывает, как эти данные должны храниться и повторно использоваться.

Записывайте событие, а не впечатление

Запишите, что именно из трёх изменилось: запись, путь к резолверу или настройка клиента. Изменение записи распространяется по собственному графику, изменение маршрута вступает в силу при переподключении, а настройка браузера действует только для этого браузера. Сведение их в одно «до и после» создаёт временную шкалу, которую никто не может проверить.

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

Выполните сравнение дважды одинаковым способом

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

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

В Windows очистка клиентского кэша очищает кэш клиента DNS и ничего больше. Она не описывает приватное состояние браузера и не очищает вышестоящий сервер, поэтому тест, построенный на ней, можно толковать только узко. Когда сообщаете результат, говорите, какой кэш вы очистили.

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