Журналы DNS-резолвера и журналы VPN-подключений: что хранит каждый

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

Два журнала, два события

Запись резолвера отвечает на вопрос об именовании: этот клиент запросил это имя в это время, и ответ был таким. Запись VPN отвечает на вопрос о связности: этот участник установил или потерял туннель, получил этот адрес и передал примерно столько данных, прежде чем исчезнуть. Ни одна не является записью о том, что пользователь делал внутри сессии HTTPS, и ни одна не заменяет другую.

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

Проследите запрос, прежде чем читать любой из журналов

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

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Последняя команда читает собственный журнал локального резолвера, что не то же самое, что журнал вышестоящего сервера. Если ваши запросы уходят через DNS over HTTPS к провайдеру, локальная заглушка может ничего не показывать, тогда как у провайдера есть полная запись, и провайдер — другой оператор с другой политикой.

Что каждая запись может и чего не может показать

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

Зашифрованный DNS меняет транспорт, а не видимость на конечной точке. Резолвер по-прежнему получает вопрос, на который отвечает, как RFC 8484 ясно показывает, и хранение на этом резолвере — решение политики, а не свойство протокола.

Где разделённый DNS и кэши путают картину

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

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

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

Задавайте вопросы о хранении отдельно

Для каждой системы задайте три вопроса: кто собирает, что собирается и как долго это хранится. Затем спросите, кто может это читать и в каком процессе. Обсуждение RFC 8484 о DNS over HTTPS — хорошее напоминание о том, что зашифрованный транспорт не убирает конечную точку, а собственная документация оператора — единственное надёжное утверждение о том, что эта точка хранит.

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

Для поиска неисправностей используйте то же разделение. Спросите, какое приложение сделало запрос и какой резолвер на него ответил, затем посмотрите в журнал, который действительно владеет этим событием. Догадка из другого журнала экономит минуту и стоит полдня.