![](https://habrastorage.org/webt/mr/gq/go/mrgqgo-gl84ckaw9gk8hv3vow3w.jpeg)
/ Unsplash / Pietro Jeng
Кто внедряет
Разработчики из Mozilla тестируют DNS-over-HTTPS еще с лета 2018-го. В феврале этого года компания сделала DoH протоколом по умолчанию для всех пользователей из США. Его поддержка автоматически активируется при установке браузера. В будущем эту практику распространят на другие страны. Что интересно, разработчики выбрали довольно агрессивную политику внедрения новинки. Firefox будет автоматически менять DNS-провайдера для пользователя, если текущий оператор не поддерживает шифрование запросов к системе доменных имен.
Внедряет DoH и другой вендор браузеров — Google. Тестировать протокол начали еще в версии Chrome 78. Полноценную поддержку добавили в публичном релизе версии 83, которая вышла месяц назад. В отличие от коллег, Google выбрали более мягкий подход ко внедрению нового протокола. Браузер корпорации включит DoH только в том случае, если провайдер пользователя находится в списке совместимых. Иначе браузер будет работать без шифрования DNS-запросов.
О чем еще мы пишем в нашем блоге на Хабре:
Новый протокол активировали и в Opera — зашифрованный трафик направляют через DNS-сервис одного из западных облачных провайдеров. Планируют внедрять DoH и авторы Brave, но пока не могут назвать точную дату реализации.
Кто выступает против
Против DNS-over-HTTPS выступают некоторые западные интернет-провайдеры. По их словам, новый протокол мешает работе системных администраторов. Поскольку трафик зашифрован, им сложнее блокировать потенциально вредоносные сайты в корпоративных и частных сетях. Протокол также усложняет поиск вирусных атак, которые уже научились инкапсулировать трафик в DoH и использовать его в своих целях. Например, летом прошлого года специалисты из Netlab обнаружили вирус Godlua. Зловред использовал DoH для получения текстовых записей (TXT) доменного имени и извлекал URL-адреса управляющих серверов.
Представители телекоммуникационных компаний также отмечают, что DoH лишает пользователей возможности настраивать функции родительского контроля — так как трафик нельзя различить. Однако разработчики браузеров предлагают варианты решения проблемы. Например, Firefox автоматически отключит DoH, если пользователь активировал функции parental controls.
![](https://habrastorage.org/webt/xc/bc/fj/xcbcfjuzls4lsvyr5kaiuvmvf8g.jpeg)
/ Unsplash / Rishi Deep
Американских телекомов также беспокоит, что такие крупные компании, как Google, могут использовать свое влияние на рынке и убедить пользователей подключиться к DNS-серверам компании. Такая ситуация может привести к централизации трафика. В конце прошлого года интернет-провайдеры даже подготовили презентацию на эту тему, с которой выступили перед членами Конгресса США. Теперь американский регулятор планирует проверить, не повредит ли DNS-over-HTTPS сетевой безопасности и здоровой конкуренции на рынке.
Свои опасения, касающиеся DoH, высказывает и регулятор Великобритании. Там провайдеры используют DNS для реализации фильтров запрещенного контента, настройка которых регламентирована законодательством. Шифрование трафика в DoH может помешать их работе. Однако в Mozilla уже отметили, что не будут активировать DNS-over-HTTPS на территории страны. Несмотря на это в British Telecommunications все равно выступают в поддержку нового протокола — в компании убеждены, что шифрование DNS-запросов повысит безопасность пользователей.
В любом случае вопрос массового распространения DNS-over-HTTPS пока остается открытым, несмотря на инициативы разработчиков браузеров. Но когда протокол начнет пользоваться больше людей, станет понятно, в каком направлении продолжит развиваться регулирование.
Материалы из нашего корпоративного блога:
litos
Почему всё же двигают DNS over HTTPS, а не DNS over TLS, уже в Linux и Android системный резолвер в настройках сети чуть-ли «из коробки» можно настроить на его использование. Я не хочу, чтобы браузер у меня куда-то лазил и резовил имена сайтов сам без ведома...
Mur81
В винде до сих пор DoT нет из коробки поэтому приходится использовать DoH. Под Android и Linux при желании в браузере можно отключить DoH и заставить его пользоваться системным резолвером.
ivan386
А eSNI будет работать при этом в браузере?
Mur81
Я не то что бы силён сильно в WEB-технологиях, но я не вижу причин почему ESNI должен отвалиться при этом. Насколько я понимаю для работы ESNI браузер должен взять из DNS открытый ключ. Каким образом он это сделает не важно.
Но я могу ошибаться.
ivan386
Браузер отрубает eSNI когда не используется DoH. eSNI просто бесполезен если домен передаётся открытым текстом в обычном DNS запросе.
Может есть настройка форсированного включения eSNI даже без DoH но я о ней не знаю.
Mur81
Возможно так и есть. Хотя на мой взгляд сказать, что ESNI совсем бесполезен без шифрования DNS это не совсем верно. Вот почему:
1. Понятно, что без шифрования DNS можно узнать куда ходил тот или иной хост, но для этого надо провести какую-то работу — сопоставить запросы DNS с последующими обращениями к IP. Но если учесть, что DNS запросы кэшируются, а на одном IP может быть много доменов, то это сопоставление не совсем элементарная задача. А открытый SNI преподносит всё на блюдечке.
2. Может быть сделано так (у меня дома сейчас так сделано) — DoH клиент поднят на роутере, а хосты из внутренней сети используют в качестве DNS сервера этот роутер, но уже по обычному 53 UDP. С точки зрения браузера на компе внутри сети что у нас — DoH или классический DNS? Думаю, что DNS. Хотя Cloudflare ESNI Checker утверждает при этом, что у меня DoH. Я ХЗ как он это делает.
Homas
2. Реализовать проверку достаточно просто:
— интеграция DNS с их страницей проверки
— выдавать различные IP/CNAME в зависимости как тот же самый запрос ресолвится (хотя если посмотреть активность даже в developer tools видно, что используют разные адреса).
После этого на странице проверки достаточно выполнить несколько GET запросов для «скачивания» удаленного объекта.
ivan386
С одной стороны DoH использует тот же порт поумолчанию что и остальной HTTPS. Таким образом его не заблокировать по номеру порта как это недавно сделал мой провайдер с 53им.
С другой любой вебсервер с может стать DNS узлом так что блокировать по IP бесполезно.
Но это даёт возможность не только браузеру общаться с DNS минуя провайдерские и пользовательские настройки системы но и скрипту на странице.
Mur81
На самом деле если провайдер захочет вам подгадить и заблокировать DoH, то это для него особого труда не составит.
Рассказываю.
Первое что он сделает это заблокирует 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 например обрабатывает криво.
Homas
Проблемы начинаются, когда какой-нибудь начнет смешивать остальной контент с DoH. Например, google.com будет отвечать на DNS запросы + закриптованный SNI. Такой трафик можно профайлить, но блокировать будет сложно.
Mur81
Верно. Только Вы забыли сказать у кого именно проблемы начнутся. Т.к. заблочат IP и сделают покерфейс. Вы спросите — а на каком основании? А на том же что человеку 53-й порт блокируют.
Но самое веселье может начаться если [когда?] суд какого-нибудь Мухосранска признает технологию опасной и РКН получит предписание её блокировать. В виду не возможности выделить трафик DoH и блокировать его отдельно знаете что они сделают? Знаете. Прецеденты мы все уже видели.
Homas
Проблемы будут у всех.
И у тех, кто пытается защитить корпоративные сети (как пример — в день когда Mozilla официально запустила DoH в США, был обнаружен вирус, который использует DoH).
У «товарища майора», который будет известным способом пытаться решить эту проблему.
А так же естественно у пользователей, которые хотят защитить свою последнюю милю.
Chupaka
А что неприемлемого в полусотне миллисекунд пинга до DNS?
Mur81
Да ничего конечно, не правильно выразился. Кроме того, что 2-5 мс как ни крути лучше чем 50-70. Но положа руку на сердце — вряд ли на глаз заметишь.
Просто я помню, что когда Cloudflare выходила на рынок, то одним из пунктов преимуществ был как раз меньший пинг. Мол у конкурентов 20, а у нас 5. И это на самом деле так и есть — у меня из большинства мест пинг до них заметно меньше чем до Гугла, который естественно и подразумевался под конкурентами. И тут на тебе — официальный DoH резолвер висит на других адресах с пингом уже не таким «вкусным».
И раз уж речь зашла о пинге, то надо понимать, что сам TCP+TLS тоже не «бесплатный» и добавит задержек по сравнению с голым UDP. Но тут уже звиняйте — за всё платить надо.
Homas
Нужно не пинг смотреть, а время ответа DNS сервера.
Mur81
Это ясно, но пинг же входит в общее время ответа. Просто этот параметр проще посмотреть и тыкать им на каждом углу.
Ну и просто со стороны Cloudflare как-то не честно что ли — сначала рекламировать маленький пинг, а потом повесить DoH резолвер на другие адреса с совсем уже другим пингом. Гугл в этом плане поступил порядочнее я считаю.
Homas
Ping это утилита, которая в данном случает измеряет сетевую задержу с помощью ICMP пакетов. ICMP показывает только приблизительно насколько «далеко» находится сервер. Но так как это другой тип пакета (в большинстве случаев имеет наименьший приоритет — почитайте по QoS), другой размер, то результаты на загруженных сетях могут значительно отличатся. + естественно никак не измеряется задержка на самом сервисе DNS (один может отвечать из кэша с 5нс, а другому будет требоваться из-за нагрузки 50мс).
Chupaka
Кстати, хорошее замечание. Причём больше даже DoT касается, наверное? Я так понимаю, DoH гораздо проще реализовать на HTTP/3 со всякими 0-RTT.
Mur81
Вот это я не знаю. Я не настолько хорошо разбираюсь в «потрохах» этих протоколов, что бы ответить. Поэтому умничать не буду.
Homas
Насколько я знаю стандарта DoH over QUIC/HTTTP/3 еще не приняли.
Наиболее простой способ для реализации на уровне DNS сервера использовать готовые библиотеки (TLS, HTTPS и т.д.), так как DNS пакет (с минимальными изменениями) просто «завернуть» в другой протокол вместо UDP/TCP.
Homas
Не все приложения хорошо это переваривают в результате чего страдает пользователь.
Например, при соединении с хабром ресолвится 9 доменов. Ну других сайтах доменом может быть гораздо больше.
Chupaka
Вот даже не знаю, что вам сказать… Из Беларуси пинги на всякие 1.1.1.1, 8.8.8.8 и прочие 9.9.9.9 и так находятся в районе 30 мс, плюс-минус, и никакого дискомфорта я не испытываю по этому поводу. До Хабра он не ниже, а там ещё и TCP Handshake, так что DNS на общем фоне погоды всё равно не делает.
Mur81
Я думаю, что не правильно говорить «из Беларуси». Это скорее от провайдера зависит. Я специально сравнивал из всех точек где у меня есть интернет по работе и личный и оказалось, что в большинстве пинг до 1.1.1.1 меньше чем до 8.8.8.8 (в среднем 2-5 против 20 мс). Но есть места где ситуация обратная.
К тому же как Homas верно заметил значимым является всё же не пинг, а совокупное время ответа сервера (куда пинг конечно тоже входит). Т.е. сервер может иметь маленький пинг, но тупить сам по себе. Просто пинг это самое простое от чего можно отталкиваться, предположив что время ответа самого сервера у таких гигантов как Гугл и Клаудфлар примерно одинаковое будет.
А так же не надо забывать, что запросы DNS кэшируются на разных этапах (в зависимости как инфраструктура реализована) и при частых запросах к одному и тому же домену ответы чаще всего будут браться из кэша. Т.е. на примере того же Хабра открытие первой страницы слегка «протупит», но все последующие будут открываться быстро т.к. весь резолв будет идти из кэша пока не истечёт TTL.
Chupaka
Ну, в Беларуси только два провайдера предоставляют доступ к международным каналам, так что тут всё немного проще :)
Кстати, был приятно удивлён тому факту, что на данный момент на 8.8.8.8 пинг всего 13 мс… Не так давно было раза в полтора-два выше. Видимо, у Гугла появился прямой стык с Белтелекомом…
З.Ы. У меня внутри Белтелекома трассировка показывает ответы 4-7 мс, так что 13 мс — это очень мало.
Homas
30мс — это уровень комфортного использования (хотя чем быстрее, тем лучше). Больше 50мс уже нежелательно.
Вот интересное исследование (хотя уже и немного устаревшее) на сравнение протоколов и влияние на загрузку web в зависимости от условий.
Mako_357
Это лишь пинг до IP. Это не означает, что имя отрезолвится за это время.
bgBrother
hosts файл или локальный кеширующий DNS поможет в любом случае.
Это не проблема технологии.
Не удивительно. Он это делает, что бы обойти потенциальную блокировку по IP.
Многие резолверы (в том числе Google) с такой задержкой резолвились уже давно и никому из рядовых пользователей это никогда не мешало.
Это не проблема технологии, но вы пишите так, как будто проблема именно в ней. Особенно на фоне заявлений, что «если провайдер захочет вам подгадить и заблокировать DoH, то это для него особого труда не составит». Труда составит. И много.
Я считаю это ложным и не постыжусь здесь это высказать. Мной представленная информация все ваши утверждения оспаривает.
P.P.S.: Легко допиливаеться в будущем или решается локальным DNS уже прямо сейчас.
Mur81
Дело в том, что я пробовал. И выглядит это так — допустим из 4-х мест отвечает по IP без проблем, а из 5-го только по имени домена, а иначе отвечает «403 Forbidden». Я не берусь это объяснить. Есть предположение, но я не настолько специалист в вебе и не хочу выглядеть идиотом (говорю честно). Если есть этому достоверное объяснение, то я бы с удовольствием послушал.
Провайдеру будет трудно заблокировать если Вы начнёте этому сопротивляться. Поднимать свои сервера, прописывать A-записи на локальном DNS, править hosts и т.д. Я с этим не спорю. Я говорю, что если вы среднестатистический юзер и прописали себе гипотетический «httрs://my-cool-dns.com/dns-query», то найти IP и заблокировать его труда не составит.
По всем остальным Вашим комментариям могу ответить тем, что я не говорил, что в технологии есть недостатки. Если это так выглядело, то извините, я не это имел в виду.
Я поделился своим опытом первого общения с технологией и рассказал о том какие есть не очевидные нюансы о которых хорошо бы знать.
А вот то, что в конкретных реализациях клиентов проблемы существуют это факт.
bgBrother
Если сервер «не видит» виртуального сервера с указанным Host в запросе («server_name 1.1.1.1»), то он может обратиться к виртуальному серверу с «server_name _;» или виртуальному серверу с указанным параметром «default_server». На месте этих виртуальных серверов может быть что угодно. К примеру, какой-то сайт или «403 Forbidden».
Вы также извините. Сейчас понял, что я мог быть слишком придирчив из-за влияния на меня части статьи.
Есть такое. Тот же TLS ECH (eSNI), кстати, находится в стадии черновика, хотя уже и реализован в FireFox.
Mur81
Вот именно так и я предположил, но с важным дополнением.
Да, тут сразу уточню, что я игрался с двумя резолверами — 1.1.1.1 и 8.8.8.8.
Так вот, возникает вопрос — почему один и тот же резолвер из одного места нормально отвечает по IP, а их другого обязательно нужно указать домен?
Я так понимаю это из-за того, что всё это лежит в CDN и обращаясь из разных мест мы по факту имеем дело разными серверами. Какие-то из них по дефолту отдают нужный нам резолвер, а каким-то нужно уточнить что мы хотим получить.
Так и есть. Кто-то из них отдавал 403, а кто-то какой-то мусор (так это выглядело в логах Микротика), похоже что просто какой-то HTML.
Но самое в этой ситуации интересное, что у меня из 4-х или 5-и мест оба эти резолвера работали по IP, а вот из одного места не работал и тоже оба. Совпадение?
bgBrother
В ином случае я мог бы подумать о вмешательстве в трафик со сбрасыванием https каким-либо методом, если подобное не учтено в реализации клиента (браузера). Этот вариант крайне сомнителен.
Mur81
Да, но я именно обратил внимание на то, что из одной точки и Гугловский и Клаудфларовский резолверы отказались отвечать по IP. Я уж было подумал, что в силу CDN не оказались ли они на одном сервере. Но разный пинг это предположение отбросил. Выходит совпадение, но весьма забавное.
Про вмешательство в трафик тоже подумал. Но после прописывания через домен всё заработало, в т.ч. и проверка сертификата проходит (в Микротиковском клиенте её можно вкл/выкл). Так что трафик похоже никто не трогает.
Homas
Некоторые продвигают DoH, потому что DoT просто заблокировать, используется выделенный порт 853/tcp.
litos
Ну ведь можно поднять сервер DNS over TLS свой на любом порту
Останется в итоге провайдеру либо закрыть вообще всё, либо использовать DPI, что также применяется
Homas
Это противоречит RFC (стандарту). Хочешь изобретать велосипед — изобретай, тебя никто не ограничивает, но применимость решения будет крайне ограниченным.
Стоимость решения DPI на весь провайдерский трафик с учетом внедрения 5g будет неподъемным.
blind_oracle
Плюс в DoH есть JSON-протокол который удобно дебажить всякими CURL, в отличии от DoT с которым приходится работать через kdig и подобное.
Homas
В RFC поддерживается только «обертка» стандартного DNS пакета. То, что поддерживает Google запросы и ответы в JSON не вошло в RFC.
blind_oracle
Ну в RFC оно (пока) может и не вошло, но все основные резолверы его поддерживают — Google, Cloudflare и опенсурсные вроде https://github.com/m13253/dns-over-https
Так что надеюсь со временем стандартизуют. Все же много проще чем wire format использовать через base64...
Homas
Wire format выбрали vs JSON (рассматривался как вариант).
Google внедрил JSON в 2016 до того как DoH был стандартизирован. В данный момент «выключать» его они пока не собираются, но это вполне возможно.
developers.google.com/speed/public-dns/docs/doh/migration
Wire format имеет преимущество, так как в случае с DoT может использоваться для трансфера DNS зон. DoH к сожалению для трансфера зон не может использоваться из-за ограничений по длине HTTP-пакета.