Инженер из Финляндии, который пишет собственный DNS-резолвер, разбирает, что провайдер может хранить, кому и когда отдавать данные, и почему заявления «privacy-first» часто звучат громче, чем юридическая реальность. Речь идёт о запросах DNS, логах и трансграничной передаче данных — там сталкиваются CLOUD Act, FISA 702, GDPR и Schrems II.

Что такое DNS-провайдер и почему он видит так много

DNS — это служба, которая переводит адрес сайта в понятный компьютеру IP-адрес. Для пользователя это выглядит как мгновенный запрос, а для провайдера — как цепочка сведений: какой домен искали, когда, с какого устройства и из какой сети.

Именно поэтому DNS-логи так ценны. По ним можно восстановить поведение человека в сети: какие сервисы он открывал, как часто и в какое время. Это не содержимое переписки, но и не безобидная техническая мелочь.

Как это работает технически

Если сервис ведёт логи, он обычно хранит не только сам домен, но и метаданные: IP клиента, время запроса, тип записи, ошибки и служебные отметки. Этого хватает, чтобы обслуживать сеть, искать сбои и фильтровать вредоносные домены.

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

На практике у провайдера есть три вещи: доступ к потоку запросов, возможность сохранить его и обязанность выполнить законное требование. Если сервис зарегистрирован в США, на него может сработать CLOUD Act; если он работает с жителями ЕС, включается GDPR. Если хотите глубже понять, как это связано с атаками на инфраструктуру и утечками, посмотрите наш разбор как проверить сайт и защитить данные.

Почему это опасно

CLOUD Act даёт американским провайдерам обязанность передать данные по запросу властей США, даже если сервер физически стоит за пределами страны. Для пользователя это означает простую вещь: расположение дата-центра не отменяет юрисдикцию компании.

FISA 702 работает иначе. Это не точечный запрос к конкретному человеку, а механизм сбора данных в интересах разведки. Если DNS-провайдер технически может отдать поток запросов, а юридически обязан это сделать, приватность держится не на рекламе, а на архитектуре и правовом статусе компании.

GDPR, наоборот, заставляет провайдера ограничивать сбор, давать понятное основание обработки и удалять данные по запросу пользователя. Статья 32 требует защищать данные, статья 33 — сообщать о серьёзной утечке в течение 72 часов, статья 17 — удалять записи по запросу в разумный срок.

Но есть важная развилка: если провайдер зарегистрирован в США или связан с американской материнской компанией, он может оказаться между двумя режимами. С одной стороны — европейские правила и договоры о передаче данных, с другой — американский запрос, который не исчезает из-за красивой страницы о приватности.

Как понять, касается ли это вас

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

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

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

Как защитить данные и снизить риск

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

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

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

Практический чек-лист

  • Посмотрите политику хранения логов у вашего DNS-сервиса.
  • Уточните, где зарегистрирована компания и кому она подчиняется юридически.
  • Проверьте, удаляет ли сервис данные по запросу и за какой срок.
  • Включите 2FA в важных аккаунтах.
  • Используйте менеджер паролей вместо повторяющихся паролей.
  • Не ставьте корпоративные и личные задачи на один и тот же профиль без необходимости.
  • Если вы работаете с чувствительными данными, выбирайте сервисы с понятной политикой шифрования и прозрачным журналированием доступа.
  • Перечитайте наш материал о защите сайта и данных при атаке, если хотите понять, как логика приватности выглядит в реальной инцидентной практике.
Поделиться: