Комментарии 47
Почему всё же двигают DNS over HTTPS, а не DNS over TLS, уже в Linux и Android системный резолвер в настройках сети чуть-ли «из коробки» можно настроить на его использование. Я не хочу, чтобы браузер у меня куда-то лазил и резовил имена сайтов сам без ведома...
В винде до сих пор DoT нет из коробки поэтому приходится использовать DoH. Под Android и Linux при желании в браузере можно отключить DoH и заставить его пользоваться системным резолвером.
А eSNI будет работать при этом в браузере?
Я не то что бы силён сильно в WEB-технологиях, но я не вижу причин почему ESNI должен отвалиться при этом. Насколько я понимаю для работы ESNI браузер должен взять из DNS открытый ключ. Каким образом он это сделает не важно.
Но я могу ошибаться.
Но я могу ошибаться.
Браузер отрубает eSNI когда не используется DoH. eSNI просто бесполезен если домен передаётся открытым текстом в обычном DNS запросе.
Может есть настройка форсированного включения eSNI даже без DoH но я о ней не знаю.
Возможно так и есть. Хотя на мой взгляд сказать, что ESNI совсем бесполезен без шифрования DNS это не совсем верно. Вот почему:
1. Понятно, что без шифрования DNS можно узнать куда ходил тот или иной хост, но для этого надо провести какую-то работу — сопоставить запросы DNS с последующими обращениями к IP. Но если учесть, что DNS запросы кэшируются, а на одном IP может быть много доменов, то это сопоставление не совсем элементарная задача. А открытый SNI преподносит всё на блюдечке.
2. Может быть сделано так (у меня дома сейчас так сделано) — DoH клиент поднят на роутере, а хосты из внутренней сети используют в качестве DNS сервера этот роутер, но уже по обычному 53 UDP. С точки зрения браузера на компе внутри сети что у нас — DoH или классический DNS? Думаю, что DNS. Хотя Cloudflare ESNI Checker утверждает при этом, что у меня DoH. Я ХЗ как он это делает.
1. Понятно, что без шифрования DNS можно узнать куда ходил тот или иной хост, но для этого надо провести какую-то работу — сопоставить запросы DNS с последующими обращениями к IP. Но если учесть, что DNS запросы кэшируются, а на одном IP может быть много доменов, то это сопоставление не совсем элементарная задача. А открытый SNI преподносит всё на блюдечке.
2. Может быть сделано так (у меня дома сейчас так сделано) — DoH клиент поднят на роутере, а хосты из внутренней сети используют в качестве DNS сервера этот роутер, но уже по обычному 53 UDP. С точки зрения браузера на компе внутри сети что у нас — DoH или классический DNS? Думаю, что DNS. Хотя Cloudflare ESNI Checker утверждает при этом, что у меня DoH. Я ХЗ как он это делает.
2. Реализовать проверку достаточно просто:
— интеграция DNS с их страницей проверки
— выдавать различные IP/CNAME в зависимости как тот же самый запрос ресолвится (хотя если посмотреть активность даже в developer tools видно, что используют разные адреса).
После этого на странице проверки достаточно выполнить несколько GET запросов для «скачивания» удаленного объекта.
— интеграция DNS с их страницей проверки
— выдавать различные IP/CNAME в зависимости как тот же самый запрос ресолвится (хотя если посмотреть активность даже в developer tools видно, что используют разные адреса).
После этого на странице проверки достаточно выполнить несколько GET запросов для «скачивания» удаленного объекта.
С одной стороны DoH использует тот же порт поумолчанию что и остальной HTTPS. Таким образом его не заблокировать по номеру порта как это недавно сделал мой провайдер с 53им.
С другой любой вебсервер с может стать DNS узлом так что блокировать по IP бесполезно.
Но это даёт возможность не только браузеру общаться с DNS минуя провайдерские и пользовательские настройки системы но и скрипту на странице.
На самом деле если провайдер захочет вам подгадить и заблокировать 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 например обрабатывает криво.
Рассказываю.
Первое что он сделает это заблокирует 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. Например, google.com будет отвечать на DNS запросы + закриптованный SNI. Такой трафик можно профайлить, но блокировать будет сложно.
Верно. Только Вы забыли сказать у кого именно проблемы начнутся. Т.к. заблочат IP и сделают покерфейс. Вы спросите — а на каком основании? А на том же что человеку 53-й порт блокируют.
Но самое веселье может начаться если [когда?] суд какого-нибудь Мухосранска признает технологию опасной и РКН получит предписание её блокировать. В виду не возможности выделить трафик DoH и блокировать его отдельно знаете что они сделают? Знаете. Прецеденты мы все уже видели.
Но самое веселье может начаться если [когда?] суд какого-нибудь Мухосранска признает технологию опасной и РКН получит предписание её блокировать. В виду не возможности выделить трафик DoH и блокировать его отдельно знаете что они сделают? Знаете. Прецеденты мы все уже видели.
Проблемы будут у всех.
И у тех, кто пытается защитить корпоративные сети (как пример — в день когда Mozilla официально запустила DoH в США, был обнаружен вирус, который использует DoH).
У «товарища майора», который будет известным способом пытаться решить эту проблему.
А так же естественно у пользователей, которые хотят защитить свою последнюю милю.
И у тех, кто пытается защитить корпоративные сети (как пример — в день когда Mozilla официально запустила DoH в США, был обнаружен вирус, который использует DoH).
У «товарища майора», который будет известным способом пытаться решить эту проблему.
А так же естественно у пользователей, которые хотят защитить свою последнюю милю.
А что неприемлемого в полусотне миллисекунд пинга до DNS?
Да ничего конечно, не правильно выразился. Кроме того, что 2-5 мс как ни крути лучше чем 50-70. Но положа руку на сердце — вряд ли на глаз заметишь.
Просто я помню, что когда Cloudflare выходила на рынок, то одним из пунктов преимуществ был как раз меньший пинг. Мол у конкурентов 20, а у нас 5. И это на самом деле так и есть — у меня из большинства мест пинг до них заметно меньше чем до Гугла, который естественно и подразумевался под конкурентами. И тут на тебе — официальный DoH резолвер висит на других адресах с пингом уже не таким «вкусным».
И раз уж речь зашла о пинге, то надо понимать, что сам TCP+TLS тоже не «бесплатный» и добавит задержек по сравнению с голым UDP. Но тут уже звиняйте — за всё платить надо.
Просто я помню, что когда Cloudflare выходила на рынок, то одним из пунктов преимуществ был как раз меньший пинг. Мол у конкурентов 20, а у нас 5. И это на самом деле так и есть — у меня из большинства мест пинг до них заметно меньше чем до Гугла, который естественно и подразумевался под конкурентами. И тут на тебе — официальный DoH резолвер висит на других адресах с пингом уже не таким «вкусным».
И раз уж речь зашла о пинге, то надо понимать, что сам TCP+TLS тоже не «бесплатный» и добавит задержек по сравнению с голым UDP. Но тут уже звиняйте — за всё платить надо.
Нужно не пинг смотреть, а время ответа DNS сервера.
Это ясно, но пинг же входит в общее время ответа. Просто этот параметр проще посмотреть и тыкать им на каждом углу.
Ну и просто со стороны Cloudflare как-то не честно что ли — сначала рекламировать маленький пинг, а потом повесить DoH резолвер на другие адреса с совсем уже другим пингом. Гугл в этом плане поступил порядочнее я считаю.
Ну и просто со стороны Cloudflare как-то не честно что ли — сначала рекламировать маленький пинг, а потом повесить DoH резолвер на другие адреса с совсем уже другим пингом. Гугл в этом плане поступил порядочнее я считаю.
Ping это утилита, которая в данном случает измеряет сетевую задержу с помощью ICMP пакетов. ICMP показывает только приблизительно насколько «далеко» находится сервер. Но так как это другой тип пакета (в большинстве случаев имеет наименьший приоритет — почитайте по QoS), другой размер, то результаты на загруженных сетях могут значительно отличатся. + естественно никак не измеряется задержка на самом сервисе DNS (один может отвечать из кэша с 5нс, а другому будет требоваться из-за нагрузки 50мс).
И раз уж речь зашла о пинге, то надо понимать, что сам TCP+TLS тоже не «бесплатный» и добавит задержек по сравнению с голым UDP. Но тут уже звиняйте — за всё платить надо.
Кстати, хорошее замечание. Причём больше даже DoT касается, наверное? Я так понимаю, DoH гораздо проще реализовать на HTTP/3 со всякими 0-RTT.
Вот это я не знаю. Я не настолько хорошо разбираюсь в «потрохах» этих протоколов, что бы ответить. Поэтому умничать не буду.
Насколько я знаю стандарта DoH over QUIC/HTTTP/3 еще не приняли.
Наиболее простой способ для реализации на уровне DNS сервера использовать готовые библиотеки (TLS, HTTPS и т.д.), так как DNS пакет (с минимальными изменениями) просто «завернуть» в другой протокол вместо UDP/TCP.
Наиболее простой способ для реализации на уровне DNS сервера использовать готовые библиотеки (TLS, HTTPS и т.д.), так как DNS пакет (с минимальными изменениями) просто «завернуть» в другой протокол вместо UDP/TCP.
Не все приложения хорошо это переваривают в результате чего страдает пользователь.
Например, при соединении с хабром ресолвится 9 доменов. Ну других сайтах доменом может быть гораздо больше.
Например, при соединении с хабром ресолвится 9 доменов. Ну других сайтах доменом может быть гораздо больше.
Вот даже не знаю, что вам сказать… Из Беларуси пинги на всякие 1.1.1.1, 8.8.8.8 и прочие 9.9.9.9 и так находятся в районе 30 мс, плюс-минус, и никакого дискомфорта я не испытываю по этому поводу. До Хабра он не ниже, а там ещё и TCP Handshake, так что DNS на общем фоне погоды всё равно не делает.
Я думаю, что не правильно говорить «из Беларуси». Это скорее от провайдера зависит. Я специально сравнивал из всех точек где у меня есть интернет по работе и личный и оказалось, что в большинстве пинг до 1.1.1.1 меньше чем до 8.8.8.8 (в среднем 2-5 против 20 мс). Но есть места где ситуация обратная.
К тому же как Homas верно заметил значимым является всё же не пинг, а совокупное время ответа сервера (куда пинг конечно тоже входит). Т.е. сервер может иметь маленький пинг, но тупить сам по себе. Просто пинг это самое простое от чего можно отталкиваться, предположив что время ответа самого сервера у таких гигантов как Гугл и Клаудфлар примерно одинаковое будет.
А так же не надо забывать, что запросы DNS кэшируются на разных этапах (в зависимости как инфраструктура реализована) и при частых запросах к одному и тому же домену ответы чаще всего будут браться из кэша. Т.е. на примере того же Хабра открытие первой страницы слегка «протупит», но все последующие будут открываться быстро т.к. весь резолв будет идти из кэша пока не истечёт TTL.
К тому же как Homas верно заметил значимым является всё же не пинг, а совокупное время ответа сервера (куда пинг конечно тоже входит). Т.е. сервер может иметь маленький пинг, но тупить сам по себе. Просто пинг это самое простое от чего можно отталкиваться, предположив что время ответа самого сервера у таких гигантов как Гугл и Клаудфлар примерно одинаковое будет.
А так же не надо забывать, что запросы DNS кэшируются на разных этапах (в зависимости как инфраструктура реализована) и при частых запросах к одному и тому же домену ответы чаще всего будут браться из кэша. Т.е. на примере того же Хабра открытие первой страницы слегка «протупит», но все последующие будут открываться быстро т.к. весь резолв будет идти из кэша пока не истечёт TTL.
Ну, в Беларуси только два провайдера предоставляют доступ к международным каналам, так что тут всё немного проще :)
Кстати, был приятно удивлён тому факту, что на данный момент на 8.8.8.8 пинг всего 13 мс… Не так давно было раза в полтора-два выше. Видимо, у Гугла появился прямой стык с Белтелекомом…
З.Ы. У меня внутри Белтелекома трассировка показывает ответы 4-7 мс, так что 13 мс — это очень мало.
Кстати, был приятно удивлён тому факту, что на данный момент на 8.8.8.8 пинг всего 13 мс… Не так давно было раза в полтора-два выше. Видимо, у Гугла появился прямой стык с Белтелекомом…
З.Ы. У меня внутри Белтелекома трассировка показывает ответы 4-7 мс, так что 13 мс — это очень мало.
30мс — это уровень комфортного использования (хотя чем быстрее, тем лучше). Больше 50мс уже нежелательно.
Вот интересное исследование (хотя уже и немного устаревшее) на сравнение протоколов и влияние на загрузку web в зависимости от условий.
Вот интересное исследование (хотя уже и немного устаревшее) на сравнение протоколов и влияние на загрузку web в зависимости от условий.
Это лишь пинг до IP. Это не означает, что имя отрезолвится за это время.
Эксперименты показали, что запись вида 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 не оказались ли они на одном сервере. Но разный пинг это предположение отбросил. Выходит совпадение, но весьма забавное.
Про вмешательство в трафик тоже подумал. Но после прописывания через домен всё заработало, в т.ч. и проверка сертификата проходит (в Микротиковском клиенте её можно вкл/выкл). Так что трафик похоже никто не трогает.
Некоторые продвигают DoH, потому что DoT просто заблокировать, используется выделенный порт 853/tcp.
Ну ведь можно поднять сервер DNS over TLS свой на любом порту
Останется в итоге провайдеру либо закрыть вообще всё, либо использовать DPI, что также применяется
Плюс в DoH есть JSON-протокол который удобно дебажить всякими CURL, в отличии от DoT с которым приходится работать через kdig и подобное.
В RFC поддерживается только «обертка» стандартного DNS пакета. То, что поддерживает Google запросы и ответы в JSON не вошло в RFC.
Ну в RFC оно (пока) может и не вошло, но все основные резолверы его поддерживают — Google, Cloudflare и опенсурсные вроде https://github.com/m13253/dns-over-https
Так что надеюсь со временем стандартизуют. Все же много проще чем wire format использовать через base64...
Wire format выбрали vs JSON (рассматривался как вариант).
Google внедрил JSON в 2016 до того как DoH был стандартизирован. В данный момент «выключать» его они пока не собираются, но это вполне возможно.
developers.google.com/speed/public-dns/docs/doh/migration
Wire format имеет преимущество, так как в случае с DoT может использоваться для трансфера DNS зон. DoH к сожалению для трансфера зон не может использоваться из-за ограничений по длине HTTP-пакета.
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?!
Пооткрывал ссылки в тексте, формулировки по источникам. Google говорит, что все у них работает и «Chrome will automatically switch to DNS-over-HTTPS if your current DNS provider supports it». Автор второй статьи также упоминает инкапсуляцию — «Godlua encapsulates its traffic streams inside of DNS over HTTPS»
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: пост поправили, стало понятнее что там происходило.
Статья ни о чем… Тема «как идет внедрение» так и не раскрыта…
Всё внедрение это обновленный микротик до последней stable прошивки.
Там достаточно будет загрузить сертификаты и прописать DNS и все… пол страны имеют шифрованный DNS. Причем даже не важна поддержка браузера, потому как клиент будет ходить до DNS сервера микротика, а от микротик дальше пойдет шифрованный.
Сам делал вот по этому мануалу — jcutrer.com/howto/networking/mikrotik/mikrotik-dns-over-https
Там достаточно будет загрузить сертификаты и прописать DNS и все… пол страны имеют шифрованный DNS. Причем даже не важна поддержка браузера, потому как клиент будет ходить до DNS сервера микротика, а от микротик дальше пойдет шифрованный.
Сам делал вот по этому мануалу — jcutrer.com/howto/networking/mikrotik/mikrotik-dns-over-https
Статья называется «Как идет внедрение», но тема нифига не раскрыта. Это не в плане, как установить свой DoH прокси, а именно, сколько процентов пользователей уже
перешли на 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, где полученные данные можно хорошо монетизировать.
перешли на 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