Отчёт о DNS через VPN: что включить, чтобы его можно было воспроизвести

«DNS сломан» — это вывод, и это не тот вывод, на основании которого помощник может что-то сделать. Полезная часть отчёта — это форма сбоя: какое имя, через какой резолвер, с каким ответом. Три детали превращают жалобу в нечто воспроизводимое, и все три безопасно публиковать после переименования приватных частей. Далее — минимум, который нужен отчёту о DNS через VPN, прежде чем кто-либо сможет помочь.

Категория имени, а не приговор

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

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

Зафиксируйте путь до резолвера

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

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

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

Укажите контролируемое сравнение

Измените одну переменную и скажите, что изменилось. Публичные имена разрешаются, а внутренние нет — это проблема выбора; каждое имя уходит в тайм-аут — это проблема пути; а приватное имя, разрешающееся в публичный адрес, — это утечка в неправильный резолвер. Две из этих трёх вещей никак не связаны с тем, поднят ли туннель. Отчёт, утверждающий, что все запросы сломаны, обычно содержит сравнение, которое так и не провели.

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

Скройте пространство имён, сохраните связи

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

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