Администраторы сетей и внимательные пользователи начиная с 21 августа фиксируют странные сбои при доступе к Google Public DNS по TCP, в то время как классический UDP продолжал работать штатно, — сообщает COMSS.
То, что происходит с 21 августа, выглядит не как единичный инцидент, а как системное обновление правил фильтрации на уровне крупных операторов — от мобильных гигантов до «Ростелекома» и региональных провайдеров вроде «Таттелекома» или петербургского SkyNet.
Как проявляется
Первые точные замеры опубликовал специализированный Telegram-канал, занимающийся обходом блокировок. Картина оказалась разной для двух основных протоколов, что сразу указывает на приборный, а не хаотичный характер вмешательства.
- DNS over TLS (DoT): Соединение с 1.1.1.1 и 1.0.0.1 на порту 853 устанавливается, но тут же сбрасывается с ошибкой
ECONNRESET. Промежуточное оборудование видит выделенный порт и режет сессию без церемоний. - DNS over HTTPS (DoH): TCP-соединение на порт 443 к dns.google или 8.8.8.8 поднимается нормально. Обрыв происходит строго после отправки клиентом
ClientHello— сервер (или то, что за ним стоит) просто перестает отвечать, уводя сессию в таймаут или сбрасывая сunexpected eof.
Это ключевой момент: IP-адреса резолверов не заблокированы целиком. Обычный нешифрованный DNS по тем же адресам часто продолжает отвечать. Блокируется именно попытка установить защищенный канал.
Почему DoH блокировать сложнее
Разница в подходах к DoT и DoH объясняется архитектурой протоколов. DoT использует выделенный порт 853 — это «светофор» для DPI-систем: увидел порт — режь соединение. С DoH всё иначе: трафик идет через порт 443, неотличимый от обычного HTTPS-веб-серфинга. Закрыть порт 443 — значит остановить интернет целиком.
Зависание сразу после ClientHello говорит о том, что фильтрация работает на уровне анализа TLS-рукопожатия. Скорее всего, оборудование инспектирует поля Server Name Indication (SNI) или отпечатки клиента (JA3/JA4), выявляя обращения к известным DNS-эндпоинтам. Ранее мы уже видели похожий вектор атаки на ECH (Encrypted Client Hello) — технологию, скрывающую имя хоста. Теперь этот метод применили точечно к публичным резолверам.
Зона поражения
Ошибаются те, кто считает проблему исключительно гугловской или клаудфловской. Уже 22 августа поступили жалобы на недоступность DoH и DoT у собственного резолвера Comss.
Причем симптомы были жестче: при настройке системы строго на защищенный DNS без фоллбэка интернет переставал работать полностью — сеть есть, а имена не разрешаются. Это подтверждает: фильтрация масштабируется на любой известный IP, ассоциируемый с публичным DNS-over-HTTPS или DNS-over-TLS.
Что делать
Стратегия «прописал 1.1.1.1 и забыл» перестала работать в российском сегменте. Необходим многоуровневый подход:
- Резервирование протоколов. Если DoH режут, попробуйте DoT (и наоборот), а также DNSCrypt — он использует свой порт 443, но другой формат пакетов, который пока реже детектится.
- Альтернативные эндпоинты. У крупных резолверов есть множество IP и хостнеймов (например,
dns.googlevs8.8.8.8). Проверяйте их по отдельности. - Локальные рекурсивные резолверы с шифрованием аплинка. Поднятие Unbound или AdGuard Home внутри сети с форвардингом на зашифрованные апстримы позволяет скрыть тот факт DNS-трафика от провайдера: для DPI это будет выглядеть как обычное HTTPS-соединение с одним удаленным хостом, а не как поток DNS-запросов.
- VPN и туннелирование. На данный момент полная инкапсуляция трафика (WireGuard, AmneziaWG, XRay/Reality) остает единственным гарантированным способом сохранить приватность DNS-запросов от провайдерского DPI.
Текущая волна блокировок демонстрирует смену парадигмы: контроль переместился с уровня IP-адресов и портов на уровень инспекции криптографических рукопожатий. Для конечного пользователя это означает необходимость уходить от простой настройки DNS в браузере к построению собственной инфраструктуры разрешения имен или использования полноценных VPN-туннелей.
Тренд очевиден, операторы получают инструменты для точечного подавления шифрованных протоколов, не ломая при этом общий веб-трафик.
Следующий этап — вероятно, блокировка по отпечаткам TLS-клиентов популярных клиентов (браузеры, systemd-resolved, клиенты DoH-прокси). Подготовка резервных сценариев разрешения имен сегодня сэкономит часы отладки завтра.
