Даже если сайт открывается по HTTPS с замком в адресной строке, провайдер всё равно может знать, куда вы обращаетесь. Причина — в DNS: протоколе, который браузер использует при каждом обращении к любому домену, ещё до начала шифрования.
DNS (Domain Name System) переводит человекочитаемые адреса, например aurashield.net, в IP-адреса, с которыми уже работают компьютеры и сети. Без этого шага устройство просто не знает, куда отправлять данные.
DNS — как справочная служба. Вы знаете имя (aurashield.net), но чтобы соединиться, нужен номер (IP-адрес). Каждый раз, когда вы «узнаёте номер», этот запрос проходит через сеть провайдера.
Стандарт DNS появился в 1983 году, задолго до того, как приватность сетевых запросов стала массовой темой. По умолчанию запрос уходит открытым текстом по UDP через порт 53 — без единого бита шифрования:
; запрос к резолверу, порт 53, без шифрования
Question: aurashield.net. IN A
Answer: aurashield.net. A 203.0.113.42Любой узел на пути этого пакета — провайдер, оператор сети Wi-Fi, сам резолвер — может прочитать имя запрошенного домена в открытом виде, никакого дешифрования не требуется.
Провайдер видит каждый DNS-запрос с точным доменным именем и временем обращения. Из этого складывается подробная картина сетевой активности:
Помимо провайдера, запросы видит и сам DNS-резолвер — сервер, который отвечает на эти запросы. Если вы не меняли настройки вручную, это резолвер провайдера; если сменили на публичный (Cloudflare, Google, Quad9) — эти запросы видит уже он.
DNS-утечка — ситуация, когда часть DNS-запросов уходит в обход зашифрованного канала, даже если для остального трафика такой канал настроен и активен.
Три стандарта шифруют сам DNS-запрос, чтобы его содержимое не читалось в открытом виде на пути к резолверу:
| Способ | Порт | Что скрывает | Особенность |
|---|---|---|---|
| DNS (обычный) | 53 / UDP | ничего — открытый текст | Провайдер видит каждый запрос |
| DoH | 443 / HTTPS | содержимое запроса | Неотличим от обычного веб-трафика |
| DoT | 853 / TLS | содержимое запроса | Отдельный порт легко выделить в трафике |
| DNSCrypt | 443 или свой | содержимое + подмену ответа | Меньше поддержки на уровне ОС и браузеров |
DNSCrypt — более старый протокол с похожей задачей: шифрует и подписывает DNS-трафик, дополнительно защищая от подмены ответа. Поддерживается меньшим числом ОС и браузеров «из коробки» — обычно нужен отдельный клиент.
Подробное сравнение портов, маскировки трафика и поддержки в браузерах и ОС — в статье «DoH против DoT: в чём разница и что выбрать».
DoH и DoT решают только часть задачи — они скрывают DNS-запрос. Но сразу после него браузер отправляет TLS ClientHello, где поле SNI (Server Name Indication) передаёт имя сайта в открытом виде — это отдельная утечка, не связанная с DNS напрямую.
Как ECH устроен внутри, какие браузеры его поддерживают и почему DoH и ECH вместе всё равно не закрывают вопрос полностью — разбор в статье «ECH и DoH: как браузер скрывает DNS и SNI от провайдера».
Публичные DNS-серверы поддерживают DoH/DoT «из коробки» и публикуют понятную политику хранения логов — в отличие от резолвера провайдера по умолчанию:
Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9) и AdGuard DNS — основные варианты с поддержкой шифрования. Их адреса, DoH/DoT-хосты и пошаговая настройка на Windows 11, macOS, Android, iPhone и роутере — в статье «1.1.1.1, 8.8.8.8, 9.9.9.9: как выбрать и настроить DNS».
Полностью убрать DNS-запросы из поля зрения провайдера можно, только направив весь сетевой трафик — включая DNS — через отдельный зашифрованный канал. В этом случае провайдер видит лишь факт подключения к серверу этого канала, но не то, какие домены вы запрашивали и какие сайты открывали.
DNS-запрос отправляется до установки HTTPS-соединения и по умолчанию идёт открытым текстом через порт 53. Замок в адресной строке защищает уже саму передачу данных страницы, но не защищает предшествующий ей DNS-запрос с именем домена.
Все три шифруют DNS-запрос, но по-разному. DoH работает через порт 443 как обычный HTTPS-трафик — незаметен на фоне остального веб-сёрфинга. DoT использует отдельный порт 853, который легче выделить в трафике. DNSCrypt дополнительно подписывает ответ от подмены, но поддерживается меньшим числом ОС и браузеров без отдельного клиента.
DNS-утечка — ситуация, когда часть DNS-запросов уходит в обход зашифрованного канала, даже если остальной трафик защищён. Частые причины: системный резолвер игнорирует настройки приложения, IPv6-запросы идут напрямую, или DoH в браузере работает параллельно с системным DNS. Проверить утечку можно на dnsleaktest.com.
Нет. DoH скрывает только содержимое DNS-запроса. После него браузер всё равно отправляет TLS ClientHello с именем сайта в поле SNI в открытом виде — эту утечку закрывает отдельная технология, ECH. Плюс остаются видимыми IP-адрес сервера и объём трафика.
ECH (Encrypted Client Hello) — расширение TLS 1.3, которое шифрует поле SNI (имя сайта) при установке соединения. Он решает другую утечку, чем DoH: DoH прячет DNS-запрос, ECH прячет имя сайта на следующем шаге. Подробности — в статье про ECH и DoH.
Единственный способ убрать все DNS-запросы из поля зрения провайдера — направить весь сетевой трафик, включая DNS, через отдельный зашифрованный канал. Тогда провайдер видит только подключение к серверу этого канала, а не то, какие домены вы запрашивали.
AuraShield направляет весь трафик, включая DNS, через зашифрованный канал. Провайдер видит только подключение к серверу — не более. Два дня бесплатно.
Попробовать бесплатно →