В российских сетях начали ограничивать защищённые DNS-сервисы Google и Cloudflare. Пользователи сразу нескольких операторов столкнулись со сбоями DNS over HTTPS и DNS over TLS, причём соединение с сервером обычно успевает установиться, а затем зависает или принудительно обрывается уже во время запуска шифрования.
Как выглядит сбой
Первые подробные замеры опубликовал 21 августа Telegram-канал bypassblock. Проверки проводились в сети мобильного оператора, и картина по двум протоколам оказалась разной.
DNS over TLS у Cloudflare перестал работать через адреса 1.1.1.1 и 1.0.0.1 на TCP-порту 853. Клиент устанавливал соединение, но затем получал ECONNRESET – то есть удалённая сторона или промежуточное оборудование принудительно сбрасывали сессию.
DNS over HTTPS у Google вёл себя иначе. При подключении к dns.google, 8.8.8.8 и 8.8.4.4 через обычный порт 443 TCP-соединение поднималось нормально. Но после отправки TLS ClientHello обмен останавливался, и клиент завершал запрос по тайм-ауту, не получив ни одного байта ответа. В части проверок соединение обрывалось прямо во время рукопожатия с ошибкой unexpected eof while reading.
Авторы канала сообщили, что получили одинаковые результаты как минимум от трёх пользователей из разных мест.
Почему DoT блокировать проще, чем DoH
Разница в поведении объясняется устройством самих протоколов.
DNS over TLS распознаётся легко: он использует выделенный TCP-порт 853, поэтому операторское оборудование определяет такой трафик уже по порту назначения и может закрыть его целиком.
С DNS over HTTPS сложнее. Запросы передаются внутри обычного HTTPS и идут через тот же порт 443, что и веб-сайты, – закрыть порт нельзя, иначе перестанет работать весь интернет. Чтобы ограничить именно DoH, нужно отличать соединения с DNS-резолверами от остального шифрованного трафика.
Зависание сразу после TLS ClientHello указывает как раз на такой уровень фильтрации: клиент успевает договориться об обычном TCP-соединении и начинает рукопожатие, но защищённый канал до DNS-сервера уже не создаётся. Отсюда и важное следствие – публичные резолверы не обязательно блокируются целиком по IP-адресу. Устройство подключается к 8.8.8.8 или 1.1.1.1, обычные незашифрованные запросы во многих сетях проходят, а вот их защищённые варианты перестают отвечать.
У каких операторов фиксируют сбои
Вслед за мобильным оператором о проблемах сообщили абоненты «Ростелекома», «Дом.ру», «Таттелекома» и петербургского SkyNet. Картина различается: у одних DoH не работал сразу через несколько публичных резолверов, у других проблемы затрагивали только отдельные адреса или один из двух протоколов. Один из абонентов «Таттелекома» рассказал, что техподдержка оператора порекомендовала отключить DoH и DoT.
Похожее случалось и раньше. В начале июля пользователи нескольких крупных операторов фиксировали проблемы с TCP-соединениями к Google Public DNS, тогда как обычные запросы по UDP продолжали проходить; через некоторое время работа восстановилась. Отличие нынешней волны в том, что жалобы касаются одновременно Google и Cloudflare и приходят от абонентов сразу нескольких операторов.
Ограничения на шифрование в российских сетях вводятся не впервые. Ранее начали блокировать сайты с поддержкой ECH – механизма Cloudflare, скрывающего имя сайта при подключении, а Роскомнадзор рекомендовал владельцам сайтов отказаться от ECH или перейти на российские CDN.
Что это значит для пользователя
DoH и DoT нужны, чтобы DNS-запросы не шли по сети открытым текстом. При классическом DNS провайдер видит, к каким доменам обращается устройство, и может вмешиваться в ответы. Защищённые протоколы шифруют обмен между устройством и выбранным резолвером.
Внешне сбой выглядит буднично: браузер или система перестаёт использовать выбранный защищённый DNS, страницы открываются с задержкой, а приложение молча переключается на другой способ разрешения имён. Если запасного варианта не предусмотрено, интернет может показаться частично неработающим, хотя соединение с сетью сохраняется.
Проблемы не только у Google и Cloudflare. Нам тоже поступали жалобы на работу Comss.one DNS по DoH. То есть фильтрация не ограничивается двумя крупнейшими публичными резолверами, и проблема шире, чем следует из первых замеров.
Первые обращения пришли 22 августа – на следующий день после замеров bypassblock. Не отвечают оба протокола: и DoH, и DoT.
Часть пользователей описывала сбой жёстче, чем зависание отдельных сайтов: после указания адреса https://dns.comss.one/dns-query интернет переставал работать совсем. Это закономерно – когда система настроена только на защищённый DNS и запасного резолвера у неё нет, оборванное соединение означает, что имена не разрешаются вообще. Сеть при этом доступна, но открыть по имени нельзя ничего.
Если защищённый DNS перестал отвечать, имеет смысл проверить, работает ли он по другому протоколу и через запасное имя сервера, – а заодно сравнить поведение в сети другого оператора. Перечень публичных резолверов с поддержкой DoH, DoT и DNSCrypt собран в разделе «Безопасные DNS».
Фильтрация DoH и DoT заметно расширяет возможности контроля DNS-трафика. До сих пор хватало одной настройки: вписать в систему или браузер публичный резолвер – и запросы уходили шифрованными мимо серверов провайдера. Теперь этого мало. Сеть оператора распознаёт саму попытку установить защищённое соединение с DNS-сервером и обрывает её независимо от того, какой адрес указан в настройках.