Comments 47
Почему всё же двигают DNS over HTTPS, а не DNS over TLS, уже в Linux и Android системный резолвер в настройках сети чуть-ли «из коробки» можно настроить на его использование. Я не хочу, чтобы браузер у меня куда-то лазил и резовил имена сайтов сам без ведома...
А eSNI будет работать при этом в браузере?
Но я могу ошибаться.
Браузер отрубает eSNI когда не используется DoH. eSNI просто бесполезен если домен передаётся открытым текстом в обычном DNS запросе.
Может есть настройка форсированного включения eSNI даже без DoH но я о ней не знаю.
1. Понятно, что без шифрования DNS можно узнать куда ходил тот или иной хост, но для этого надо провести какую-то работу — сопоставить запросы DNS с последующими обращениями к IP. Но если учесть, что DNS запросы кэшируются, а на одном IP может быть много доменов, то это сопоставление не совсем элементарная задача. А открытый SNI преподносит всё на блюдечке.
2. Может быть сделано так (у меня дома сейчас так сделано) — DoH клиент поднят на роутере, а хосты из внутренней сети используют в качестве DNS сервера этот роутер, но уже по обычному 53 UDP. С точки зрения браузера на компе внутри сети что у нас — DoH или классический DNS? Думаю, что DNS. Хотя Cloudflare ESNI Checker утверждает при этом, что у меня DoH. Я ХЗ как он это делает.
— интеграция DNS с их страницей проверки
— выдавать различные IP/CNAME в зависимости как тот же самый запрос ресолвится (хотя если посмотреть активность даже в developer tools видно, что используют разные адреса).
После этого на странице проверки достаточно выполнить несколько GET запросов для «скачивания» удаленного объекта.
С одной стороны DoH использует тот же порт поумолчанию что и остальной HTTPS. Таким образом его не заблокировать по номеру порта как это недавно сделал мой провайдер с 53им.
С другой любой вебсервер с может стать DNS узлом так что блокировать по IP бесполезно.
Но это даёт возможность не только браузеру общаться с DNS минуя провайдерские и пользовательские настройки системы но и скрипту на странице.
Рассказываю.
Первое что он сделает это заблокирует 443 TCP на общеизвестные резолверы, такие как 1.1.1.1 и 8.8.8.8.
Тут вы скажете — хрен с тобой золотая рыбка, я сейчас возьму какой-то малоизвестный резолвер и замаешься ты IP вычислять т.к. трафик неотличим от HTTPS.
И вот тут оказывается, что ни хрена подобного. Дело в том, что в качестве DoH резолвера используется адрес такого вот вида (для простоты буду на примере Cloudflare показывать):
httрs://1dot1dot1dot1.cloudflare-dns.com/dns-query
Соответственно что бы клиенту DoH установить соединение с сервером он должен сначала разрешить домен 1dot1dot1dot1.cloudflare-dns.com в IP адрес. И как вы думаете он это делает? Правильно — с помощью классического DNS через 53 UDP.
Получается, что для провайдера всё прозрачно — вы, как абонент, постоянно генерируете классический DNS трафик с запросом одного единственного домена, а затем у вас с полученным IP постоянно висят TCP соединения на 443-м порту. А это значит мы получили IP резолвера, который можем блокировать.
Теперь вы говорите — ок, я всех умнее, я вручную резолвну домен 1dot1dot1dot1.cloudflare-dns.com, получу его IP (в данном случае это 1.1.1.1) и запишу адрес резолвера вот так:
httрs://1.1.1.1/dns-query
Тогда клиенту DoH не надо будет резолвить домен через классический DNS и засвечивать адрес резолвера. Так-то оно так, да не совсем. Эксперименты показали, что запись вида httрs://1.1.1.1/dns-query работает далеко не всегда. Почему я не знаю. Есть кое какие предположения, но озвучивать я их не буду наверно (потому что сильно не уверен).
Обходом этой ситуации может являться прописывание статических A-записей на клиенте DoH, так что бы он мог обратиться к резолверу по имени домена, но при этом не лезть за IP адресом на классический DNS. Но:
Во-первых не всякий клиент позволяет провернуть такой фокус.
Во-вторых некоторые резолверы постоянно меняют IP адреса. Например cloudflare-dns.com резолвится вовсе не в 1.1.1.1/1.0.0.1, а в совершенно «не красивые» адреса и они постоянно меняются. Мало того, я уже сталкивался с тем, что некоторые из этих адресов лежат, а DoH клиент эту ситуацию обрабатывает криво и впадает в ступор (это отдельная тема).
К тому же если до 1.1.1.1/1.0.0.1 я имею пинг в среднем 2-5 мс, то до адресов в которые резолвится cloudflare-dns.com пинг может быть непредсказуемо какой угодно, вплоть до десятков мс, что уже не приемлемо.
При этом httрs://cloudflare-dns.com/dns-query это «законный» документированный резолвер, а вот httрs://1dot1dot1dot1.cloudflare-dns.com/dns-query (который резолвится в 1.1.1.1/1.0.0.1) это не документированный резолвер (как я понял). Теоретически он может в любой момент перестать отвечать на DoH запросы.
(У гугла в этом плане проще — у него что так, что сяк два адреса — 8.8.8.8/8.8.4.4)
И это ещё не всё.
Взять тот же Хром, в котором якобы добавили полноценную поддержку. Так вот, в нём нельзя прописать свой DoH резолвер. Он поддерживает только два провайдера — Cloudflare и Google. И адреса резолверов (httрs://cloudflare-dns.com/dns-query и httрs://dns.google/dns-query) в нём просто захардкожены.
Вот такая интересная картина вырисовывается когда в эту тему начинаешь погружаться.
Резюме в общем такое — DoH отлично позволяет скрыть свой DNS трафик от посторонних глаз и не позволит провайдеру подменить вам DNS сервер. Но ежели провайдер задасться целью заблокировать вам всю малину, то все средства для этого у него найдутся. Бороться с этм можно конечно. Можно поднять свой DoH резолвер и заставить его отвечать на запросы без указания домена, например. Но выплывают другие проблемы. Например Хром не заставишь работать с таким резолвером. Я думаю в будущем они этот бред конечно исправят, но всё же.
PS Внимание! В комментарии все «https» написаны с русской буквой «р». Иначе Хабр съедает префикс, а в данном случае это важно для наглядности. Поэтому не надо делать копипасту не глядя!
PPS И это я ещё не поднял тему отказоустойчивости. Т.к. классические DNS обычно прописываются в количестве минимум двух штук — скажем 8.8.8.8 и 1.1.1.1 (упал Гугл, работаем с Клаудфларом). А вот DoH/DoT везде где я видел прописывается один. И даже если там домен резолвится в пул адресов, и один адрес из пула упал, то [как я выше писал] не факт, что клиент обработает эту ситуацию корректно. MikroTik например обрабатывает криво.
Но самое веселье может начаться если [когда?] суд какого-нибудь Мухосранска признает технологию опасной и РКН получит предписание её блокировать. В виду не возможности выделить трафик DoH и блокировать его отдельно знаете что они сделают? Знаете. Прецеденты мы все уже видели.
И у тех, кто пытается защитить корпоративные сети (как пример — в день когда Mozilla официально запустила DoH в США, был обнаружен вирус, который использует DoH).
У «товарища майора», который будет известным способом пытаться решить эту проблему.
А так же естественно у пользователей, которые хотят защитить свою последнюю милю.
А что неприемлемого в полусотне миллисекунд пинга до DNS?
Просто я помню, что когда Cloudflare выходила на рынок, то одним из пунктов преимуществ был как раз меньший пинг. Мол у конкурентов 20, а у нас 5. И это на самом деле так и есть — у меня из большинства мест пинг до них заметно меньше чем до Гугла, который естественно и подразумевался под конкурентами. И тут на тебе — официальный DoH резолвер висит на других адресах с пингом уже не таким «вкусным».
И раз уж речь зашла о пинге, то надо понимать, что сам TCP+TLS тоже не «бесплатный» и добавит задержек по сравнению с голым UDP. Но тут уже звиняйте — за всё платить надо.
Ну и просто со стороны Cloudflare как-то не честно что ли — сначала рекламировать маленький пинг, а потом повесить DoH резолвер на другие адреса с совсем уже другим пингом. Гугл в этом плане поступил порядочнее я считаю.
И раз уж речь зашла о пинге, то надо понимать, что сам TCP+TLS тоже не «бесплатный» и добавит задержек по сравнению с голым UDP. Но тут уже звиняйте — за всё платить надо.
Кстати, хорошее замечание. Причём больше даже DoT касается, наверное? Я так понимаю, DoH гораздо проще реализовать на HTTP/3 со всякими 0-RTT.
Наиболее простой способ для реализации на уровне DNS сервера использовать готовые библиотеки (TLS, HTTPS и т.д.), так как DNS пакет (с минимальными изменениями) просто «завернуть» в другой протокол вместо UDP/TCP.
Например, при соединении с хабром ресолвится 9 доменов. Ну других сайтах доменом может быть гораздо больше.
К тому же как Homas верно заметил значимым является всё же не пинг, а совокупное время ответа сервера (куда пинг конечно тоже входит). Т.е. сервер может иметь маленький пинг, но тупить сам по себе. Просто пинг это самое простое от чего можно отталкиваться, предположив что время ответа самого сервера у таких гигантов как Гугл и Клаудфлар примерно одинаковое будет.
А так же не надо забывать, что запросы DNS кэшируются на разных этапах (в зависимости как инфраструктура реализована) и при частых запросах к одному и тому же домену ответы чаще всего будут браться из кэша. Т.е. на примере того же Хабра открытие первой страницы слегка «протупит», но все последующие будут открываться быстро т.к. весь резолв будет идти из кэша пока не истечёт TTL.
Кстати, был приятно удивлён тому факту, что на данный момент на 8.8.8.8 пинг всего 13 мс… Не так давно было раза в полтора-два выше. Видимо, у Гугла появился прямой стык с Белтелекомом…
З.Ы. У меня внутри Белтелекома трассировка показывает ответы 4-7 мс, так что 13 мс — это очень мало.
Эксперименты показали, что запись вида httрs://1.1.1.1/dns-query работает далеко не всегда. Почему я не знаю. Есть кое какие предположения, но озвучивать я их не буду наверно (потому что сильно не уверен).Я бы советовал выбрать другой резолвер и проверить его доступность по IP в таком виде. Ставить под сомнение всю технологию подобными тезисами — некорректно.
Во-первых не всякий клиент позволяет провернуть такой фокусhosts файл или локальный кеширующий DNS поможет в любом случае.
Во-вторых некоторые резолверы постоянно меняют IP адресаЭто не проблема технологии.
Например cloudflare-dns.com резолвится вовсе не в 1.1.1.1/1.0.0.1, а в совершенно «не красивые» адреса и они постоянно меняются.Не удивительно. Он это делает, что бы обойти потенциальную блокировку по IP.
вплоть до десятков мс, что уже не приемлемо.Многие резолверы (в том числе Google) с такой задержкой резолвились уже давно и никому из рядовых пользователей это никогда не мешало.
Взять тот же Хром, в котором якобы добавили полноценную поддержку. Так вот, в нём нельзя прописать свой DoH резолвер.Это не проблема технологии, но вы пишите так, как будто проблема именно в ней. Особенно на фоне заявлений, что «если провайдер захочет вам подгадить и заблокировать DoH, то это для него особого труда не составит». Труда составит. И много.
Но ежели провайдер задасться целью заблокировать вам всю малину, то все средства для этого у него найдутся.Я считаю это ложным и не постыжусь здесь это высказать. Мной представленная информация все ваши утверждения оспаривает.
PPS И это я ещё не поднял тему отказоустойчивости. Т.к. классические DNS обычно прописываются в количестве минимум двух штук — скажем 8.8.8.8 и 1.1.1.1 (упал Гугл, работаем с Клаудфларом). А вот DoH/DoT везде где я видел прописывается один.P.P.S.: Легко допиливаеться в будущем или решается локальным DNS уже прямо сейчас.
Я бы советовал выбрать другой резолвер и проверить его доступность по IP в таком виде.
Дело в том, что я пробовал. И выглядит это так — допустим из 4-х мест отвечает по IP без проблем, а из 5-го только по имени домена, а иначе отвечает «403 Forbidden». Я не берусь это объяснить. Есть предположение, но я не настолько специалист в вебе и не хочу выглядеть идиотом (говорю честно). Если есть этому достоверное объяснение, то я бы с удовольствием послушал.
Я считаю это ложным и не постыжусь здесь это высказать. Мной представленная информация все ваши утверждения оспаривает.
Провайдеру будет трудно заблокировать если Вы начнёте этому сопротивляться. Поднимать свои сервера, прописывать A-записи на локальном DNS, править hosts и т.д. Я с этим не спорю. Я говорю, что если вы среднестатистический юзер и прописали себе гипотетический «httрs://my-cool-dns.com/dns-query», то найти IP и заблокировать его труда не составит.
По всем остальным Вашим комментариям могу ответить тем, что я не говорил, что в технологии есть недостатки. Если это так выглядело, то извините, я не это имел в виду.
Я поделился своим опытом первого общения с технологией и рассказал о том какие есть не очевидные нюансы о которых хорошо бы знать.
А вот то, что в конкретных реализациях клиентов проблемы существуют это факт.
И выглядит это так — допустим из 4-х мест отвечает по IP без проблем, а из 5-го только по имени домена, а иначе отвечает «403 Forbidden»
Если есть этому достоверное объяснение, то я бы с удовольствием послушал.Вероятно из-за таковой «политики» резолвера и конфигурации его серверов (default_server, server_name и прочее при разном ПО).
Если сервер «не видит» виртуального сервера с указанным Host в запросе («server_name 1.1.1.1»), то он может обратиться к виртуальному серверу с «server_name _;» или виртуальному серверу с указанным параметром «default_server». На месте этих виртуальных серверов может быть что угодно. К примеру, какой-то сайт или «403 Forbidden».
Если это так выглядело, то извините, я не это имел в виду.Вы также извините. Сейчас понял, что я мог быть слишком придирчив из-за влияния на меня части статьи.
А вот то, что в конкретных реализациях клиентов проблемы существуют это факт.Есть такое. Тот же TLS ECH (eSNI), кстати, находится в стадии черновика, хотя уже и реализован в FireFox.
Если сервер «не видит» виртуального сервера с указанным Host в запросе («server_name 1.1.1.1»), то он может обратиться к виртуальному серверу с «server_name _;» или виртуальному серверу с указанным параметром «default_server». На месте этих виртуальных серверов может быть что угодно. К примеру, какой-то сайт или «403 Forbidden».
Вот именно так и я предположил, но с важным дополнением.
Да, тут сразу уточню, что я игрался с двумя резолверами — 1.1.1.1 и 8.8.8.8.
Так вот, возникает вопрос — почему один и тот же резолвер из одного места нормально отвечает по IP, а их другого обязательно нужно указать домен?
Я так понимаю это из-за того, что всё это лежит в CDN и обращаясь из разных мест мы по факту имеем дело разными серверами. Какие-то из них по дефолту отдают нужный нам резолвер, а каким-то нужно уточнить что мы хотим получить.
К примеру, какой-то сайт или «403 Forbidden».
Так и есть. Кто-то из них отдавал 403, а кто-то какой-то мусор (так это выглядело в логах Микротика), похоже что просто какой-то HTML.
Но самое в этой ситуации интересное, что у меня из 4-х или 5-и мест оба эти резолвера работали по IP, а вот из одного места не работал и тоже оба. Совпадение?
Но самое в этой ситуации интересное, что у меня из 4-х или 5-и мест оба эти резолвера работали по IP, а вот из одного места не работал и тоже оба. Совпадение?Скорее всего из этих двух мест в зависимости от геолокации/маршрутов запросы уходят на разные сервера резолвера (у которых разная конфигурация), как выше и описали.
В ином случае я мог бы подумать о вмешательстве в трафик со сбрасыванием https каким-либо методом, если подобное не учтено в реализации клиента (браузера). Этот вариант крайне сомнителен.
Скорее всего из этих двух мест в зависимости от геолокации/маршрутов запросы уходят на разные сервера резолвера
Да, но я именно обратил внимание на то, что из одной точки и Гугловский и Клаудфларовский резолверы отказались отвечать по IP. Я уж было подумал, что в силу CDN не оказались ли они на одном сервере. Но разный пинг это предположение отбросил. Выходит совпадение, но весьма забавное.
Про вмешательство в трафик тоже подумал. Но после прописывания через домен всё заработало, в т.ч. и проверка сертификата проходит (в Микротиковском клиенте её можно вкл/выкл). Так что трафик похоже никто не трогает.
Ну ведь можно поднять сервер DNS over TLS свой на любом порту
Останется в итоге провайдеру либо закрыть вообще всё, либо использовать DPI, что также применяется
Плюс в DoH есть JSON-протокол который удобно дебажить всякими CURL, в отличии от DoT с которым приходится работать через kdig и подобное.
Ну в RFC оно (пока) может и не вошло, но все основные резолверы его поддерживают — Google, Cloudflare и опенсурсные вроде https://github.com/m13253/dns-over-https
Так что надеюсь со временем стандартизуют. Все же много проще чем wire format использовать через base64...
Google внедрил JSON в 2016 до того как DoH был стандартизирован. В данный момент «выключать» его они пока не собираются, но это вполне возможно.
developers.google.com/speed/public-dns/docs/doh/migration
Wire format имеет преимущество, так как в случае с DoT может использоваться для трансфера DNS зон. DoH к сожалению для трансфера зон не может использоваться из-за ограничений по длине HTTP-пакета.
Полноценную поддержку добавили в публичном релизе версии 83
В 83-м релизе до сих пор DoH надо включать через флаги. Уже много где видел, что там добавили полноценную поддержку но так и не понял где она?
которые уже научились инкапсулировать трафик в DoH и использовать его в своих целях
Интересная фраза с учётом того, что трафик DoH это обычный HTTPS трафик.
Он обращался к новому протоколу и извлекал из него URL-адреса управляющих серверов
Извлекал URL-адреса из DNS?!
Chrome will automatically switch to DNS-over-HTTPS if your current DNS provider supports it
Дело в том, что я в новостях видел скриншоты где прямо в настройках Хрома можно настраивать DoH. У меня в настройках ничего такого так и не появилось и судя по комментариям под теми новостями не только у меня. Возможно они конечно включили DoH по умолчанию, но управляется это до сих пор через флаги. У меня DoH был включен везде с самого начала его появления, так что я не могу теперь сказать включается ли он по дефолту. Да и не так это важно, просто на мой взгляд это трудно назвать полноценной поддержкой. По сравнению хотя бы как это сделано в FF, где можно в настройках включить/выключить, поставить на автомат или настроить руками нужный резолвер.
Godlua encapsulates its traffic streams inside of DNS over HTTPS
Я конечно подозреваю, что ни возможно имели в виду DNS tunneling только через DoH. Но всё равно звучит забавно, т.к. если у тебя есть уже доступ по 443 TCP, то какой смысл извращаться туннелируя через DSN? Ну может я чего не понимаю.
Upd: пост поправили, стало понятнее что там происходило.
Там достаточно будет загрузить сертификаты и прописать DNS и все… пол страны имеют шифрованный DNS. Причем даже не важна поддержка браузера, потому как клиент будет ходить до DNS сервера микротика, а от микротик дальше пойдет шифрованный.
Сам делал вот по этому мануалу — jcutrer.com/howto/networking/mikrotik/mikrotik-dns-over-https
перешли на DoH (добровольно или принудительно).
Приведена информация о поддержке браузерами и т.д. и т.п. Какой процент пользователей перешел на DoH — ничего, какие провайдеры тестируют — ничего, кто уже предлагает (кроме Cloudflare и Google) — тоже ничего. Поэтому я и написал, что пост ни о чем…
У «пол страны» нет микротиков + заниматься этим будут только те, кто понимает, что это такое. Ну и в любом случае если используешь публичные DoH сервера ты свои запросы сливаешь «большому брату», так как пока нет авторитативных серверов поддерживающих DoT/DoH. В этом смысле DNS какого-нибудь маленького провайдера может более приватным, чем гугловский DoH. Самое оптимальное иметь свой DNS где-нибудь в удаленном Cloud (например бесплатная VM от Oracle вполне подойдет).
+ Реализация DoH на маршрутизаторе (без фильтрации трафика) тебя не спасет от устройств/приложений/вирусов которым вдруг вздумается напрямую общаться с другим DoH.
Я на своем DNS (open source проект) я реализовал DoT почти 1.5 года назад, а DoH чуть меньше года назад. Сложного в этом ничего нет.
Если по теме, то есть большое сомнение, что Mozilla будет активно пихать это решение в РФ. Судя по тому как они просто отказались от внедрения DoH в UK можно судить, что в других странах, кому это не нужно, (например РФ) произойдет тоже самое.
В данный момент Mozilla пушит DoH только в США (правда доля рынка FF мала), скорее всего Mozilla и Cloudflare (они активно пропихивали RFC — приняли где-то за год или полтора) просто захотели получить как минимум американский рынок DNS, где полученные данные можно хорошо монетизировать.
Американских телекомов также беспокоит, что такие крупные компании, как Google, могут использовать свое влияние на рынке и убедить пользователей подключиться к DNS-серверам компании. Такая ситуация может привести к централизации трафика. В конце прошлого года интернет-провайдеры даже подготовили презентацию на эту тему, с которой выступили перед членами Конгресса США. Теперь американский регулятор планирует проверить, не повредит ли DNS-over-HTTPS сетевой безопасности и здоровой конкуренции на рынке.Вот же ****. А что им мешает поднять свой DoH резолвер и дать инструкцию пользователям как его использовать? О какой централизации речь? Браузеры не дают возможности сменить резолвер?
Эти телекомы в курсе, что никто и не будет использовать их резолвер после всех тех редиректов и продаж пользовательских данных, которыми часть из них занимается прямо сейчас, избавиться от чего возможно было только наигравшись с DNSCrypt/аналогами.
Выдержал примерно месяц дох. Задержки адовые, 3 из 10 запросов не возвращают записи. Если такое включат, пользователи взвоют.
Как идет внедрение DNS-over-HTTPS