Комментарии 56
По его мнению, новая технология не даст эффективно контролировать работу сетей. Например, системные администраторы не смогут блокировать потенциально вредоносные сайты, а рядовые пользователи будут лишены возможности организации родительского контроля в браузерах.это как критиковать строителей моста что после постройки, плохие люди смогут убегать по мосту на другой берег О_о! ну так и хорошие смогут, для этого мост и делают.
Там ещё в комментариях забавно. "network operators must be able to monitor and filter it.Use DoT, never DoH.".
То есть конкурирующий DoT сразу разрабатывается с прицелом на возможность фильтрации. Зря Гугл его за компанию поддерживает, их голос мог быть решающим.
А чем конкретно DoT отличается настолько принципиально, что создаёт возможность просматривать/фильтровать трафик? Если речь о том, что будет использовать MItM на левых сертификатах, то с DoH можно делать ровно то же самое, просто чуток сложнее — надо не просто перехватить запрос и ответить самостоятельно, а перехватить, проанализировать это запрос к /dns-query или нет, в первом случае ответить самостоятельно, во втором проксировать запрос реальному серверу.
Написано же в статье.
DoT использует отдельный порт 853 и провайдер может просто его заблокировать и тем самым отключить DoT и вынудить клиента использовать нешифрованный DNS. Чтобы провайдер мог блокировать нехорошие сайты и продавать аналитику о пользователях.
DoH с виду выглядит как HTTPS и его блокировать труднее.
DoT использует отдельный порт 853 и провайдер может просто его заблокировать и тем самым отключить DoT и вынудить клиента использовать нешифрованный DNS. Чтобы провайдер мог блокировать нехорошие сайты и продавать аналитику о пользователях.
DoH с виду выглядит как HTTPS и его блокировать труднее.
У меня была такая мысль, но, всё же, есть разница между "заблокировать" и "просматривать/фильтровать". Так что я понадеялся, что дело в чём-то другом.
Но для резолва через DoH все равно нужен IP адрес.
Ну будут блокировать 1.1.1.1:443 вместо 1.1.1.1:853, невелика беда.
Это сложнее, так как любой может поднять DoH сервер и сообщить о нем в чатике по интересам, и надо тратить силы на поиск всех этих серверов. Как с Телеграмом.
DoT не запрещает использовать любой другой порт, так что в теории и с ним это возможно, если есть возможность сконфигурировать.
Но так клиент должен тоже уметь возможность настраивать порт для DNS-сервера. Либо в домашних условиях можно поднять сервер в локальной сети, который может соединяться посредством DoT и с него раздавать устройствам.
Варианты, в общем, есть. Но это конечно уже не добавил и пошёл, как в случае с DoH, тут вы правы.
Вы что думаете, там один адрес? Теоритически любой адрес из Cloudflare может стать им. Ясно вам?
для широкого распространения протокола DoH на практике потребуется пара десятилетий
Не слишком ли долго на распространение технологии? Ее и сейчас уже активно используют через приложение от Claudflare.
А то, что в DoH перформанс просто никакой относительно обычного DNS почему не упомянуто? Т.е. вместо одного UDP-запроса и ответа надо поднять TCP (3-4 пакета), установить SSL (ещё 3 пакета? не помню уже), обернуть весь запрос в http, увеличив payload, с той стороны распарсить и вернуть.
А если DoH-сервер решит идти к вышестоящим по DoH… Явно направление неверное.
DoT всё-же чуть легче, но тоже в целом, тяжеловат, а проблемы с тем, что используется отдельный порт мне не кажутся проблемами, если не видно, что происходит внутри. Любой компьютер посылает DNS-запросы, это не является проблемой и экзотикой. Будет просто посылать через другой порт. А вот если компьютер не посылает запросы, но при этом ходит в интернет, это уже подозрительная личность.
А если DoH-сервер решит идти к вышестоящим по DoH… Явно направление неверное.
DoT всё-же чуть легче, но тоже в целом, тяжеловат, а проблемы с тем, что используется отдельный порт мне не кажутся проблемами, если не видно, что происходит внутри. Любой компьютер посылает DNS-запросы, это не является проблемой и экзотикой. Будет просто посылать через другой порт. А вот если компьютер не посылает запросы, но при этом ходит в интернет, это уже подозрительная личность.
А то, что в DoH перформанс просто никакой относительно обычного DNS почему не упомянуто?
Тут выбор между «совсем никакой… вообще никак ибо заблокировали» и «медленне, но как-то работает».
Явно направление неверное.
Работающее «как-то» явно лучше неработающего «вообще никак» :)
Вот именно. Что мне толку от перформанса, если я не могу вообще попасть на нужный сайт, а вижу вместо него заглушку провайдера о том, что какой-то И.П Рак вдруг решил, что этот сайт мне посещать не следует.
+1
Когда у меня в Крыму отрубился ДНС провайдера (профукали сертификаты, говорят), то включение RTT в Firefox «внезапно»™ решило проблему, пока народ двое суток повизгивал в единственном средстве коммуникации с провайдером — вконтактике с мобильного :/
Уже с месяц RTT (т.е. DoH) включён принудительно и совершенно не испытываю проблем с задержками. Если не брать ситуацию, когда мне надо опросить 100500 разных dns имен подряд, то, с учетом даже минимального кеширования, разница не ощутима.
ЗЫ: вторую неделю неспешно «мечтаю» прикрутить это дело к микротику, но ничего, кроме MetaRouter пока не вырисовывается, а оно глючное…
Когда у меня в Крыму отрубился ДНС провайдера (профукали сертификаты, говорят), то включение RTT в Firefox «внезапно»™ решило проблему, пока народ двое суток повизгивал в единственном средстве коммуникации с провайдером — вконтактике с мобильного :/
Уже с месяц RTT (т.е. DoH) включён принудительно и совершенно не испытываю проблем с задержками. Если не брать ситуацию, когда мне надо опросить 100500 разных dns имен подряд, то, с учетом даже минимального кеширования, разница не ощутима.
ЗЫ: вторую неделю неспешно «мечтаю» прикрутить это дело к микротику, но ничего, кроме MetaRouter пока не вырисовывается, а оно глючное…
Что-то не могу нагуглить, как включить, поделитесь, плиз.
Где-то недавно мелькало, могу всё не вспомнить:
* about:config
* networking.trr.mode = 2
* networking.trr.uri = 'https://cloudflare-dns.com/dns-query'
смотреть, что оно работает через about:networking -> dns
Про варианты trr.mode — гуглить возможные варианты (2 = предпочитать DoH, fallback to DNS)
ЗЫ: Firefox должен быть достаточно свежий, точно не помню, но, что-то типа выше 60.3
* about:config
* networking.trr.mode = 2
* networking.trr.uri = 'https://cloudflare-dns.com/dns-query'
смотреть, что оно работает через about:networking -> dns
Про варианты trr.mode — гуглить возможные варианты (2 = предпочитать DoH, fallback to DNS)
ЗЫ: Firefox должен быть достаточно свежий, точно не помню, но, что-то типа выше 60.3
Начиная с Firefox 63 это настраивается в обычных графических настройках, в настройках сети.
вторую неделю неспешно «мечтаю» прикрутить это дело к микротикуforum.mikrotik.com/viewtopic.php?f=2&t=132678#p693725
Ну, с приходом TLS 1.3 и 0-RTT Handshake все уже не так плохо. Первое соединение будет долгое, да. А повторные уже будут устанавливаться намного быстрее. Да и в http есть keep-alive.
Тем более, в RFC указан HTTP/2 как минимально рекомендуемый стандарт. То есть, в будущем скорее всего будет и HTTP/3, который сделан поверх UDP/QUIC.
Тем более, в RFC указан HTTP/2 как минимально рекомендуемый стандарт. То есть, в будущем скорее всего будет и HTTP/3, который сделан поверх UDP/QUIC.
С точки зрения серверов — возможно. Мне, как пользователю всё равно. Как ниже отметили, я лучше подожду 6 пакетов до результата, чем один пакет до заглушки.
Мне вот другое интересно. DNS это дерево кэширующих серверов. Когда я обращаюсь к серверу провайдера, он кэширует последние ответы, его вышестоящий кэширует и т.д., снижая нагрузку на корневые серверы. С DoH и DoT мы централизируемся?
Нет, просто можно считать другим протоколом для общения с DNS-сервером.
Я тогда не понимаю. Ну, допустим мы обращаемся к 127.0.0.1:53@udp локально, он связывается со своим 1.1.1.1 на амазоне. А дальше? Амазон использует обычный DNS и это защита от манипуляций со стороны провайдера и не более? Как, например, это остановит манипуляции со стороны амазона?
1.1.1.1 — на CloudFlare, дальше он может пойти тем же протоколом, это ничему не мешает, но скорее всего пойдёт обычным DNS или DNSSec.
В основном, эта защита именно от манипуляций со стороны провайдера.
В основном, эта защита именно от манипуляций со стороны провайдера.
Да вроде уже не мало — DoH и не должен был решить сразу все проблемы
Тут надо разделять приватность и целостность. Обертки типа DoH и DoT обеспечивают исключительно приватность от клиента до сервера, к которому направляется запрос. Если же DNS-сервис, TLD и запрашиваемый домен поддерживают DNSSec и соответствующая информация возвращается в запросе (так делает, например, 1.1.1.1), записи DNSSec позволяют автоматически осуществить именно проверку целостности: не подменил ли кто-то ответ.
Хорошо, я включу эту опцию в Firefox. Так у меня перестанут работать сайты, у которых есть разные внутренние и наружние адреса. Всё будет как будто я не внутри сети, а снаружи.
Почему?
Допустим есть адрес внутренней сети организации server.my.net, которому соответствует адрес 192.168.0.111 из приватного диапазона внутри сети и 12.34.56.78 снаружи. По первому адресу доступны корпоративные ресурсы, по второму — только интерфейс для клиентов. Так как в DoH запрос пойдёт скорее всего напрямую до какого-нибудь гугла, он вернёт естественно публичный адрес. Но тут другой вопрос, если такие сложности с одной довольно редкой ситуацией, почему просто не добавить в закладки браузера нужный внутренний айпишник?
Это что за организация такая, где можно делать в сети то, что хочешь? Если вы админ, то найдёте способ как это обойти, а если пользователь сети, то посоветуйтесь с админом. Хотя, в большинстве случаев просто получите звиздюдей от начальника за то, что в рабочее время занимаетесь не тем, чем надо :)
Мне тоже кажется, что ситуация надуманная, просто попытался ответить на вопрос выше :) Меня, как человека, использующего свой DNS в том числе для борьбы с рекламой и трекингом, больше волнует, что распространение DoH снизит эффективность такого подхода или вообще сведет его на нет, если каждое приложение и браузер будут лезть в свой DNS ресолвер через туннель
Мне тоже DoH не нужен от слово совсем ибо это тормоза и ужас, у меня есть быстрый кэширующий DNS, который отвечает из локалки за 0.5-0.6 мс, а любой запрос которого нет в кэше получает за 2-7 мс от серверов (провайдера (Онлайм), Google, Яндекс, Cloudflare и системы OpenNIC), и только редкие запросы уходят от DNS к которым обращаюсь дальше к корням. В общем вся инфраструктура недалеко от меня и переводить эту красоту на убогий HTTPS это бред и деградация.
Снизить эффективность выкрамсывания следилок и мусора может но не досконально ибо если есть свой DNS, то вместо, например, dns.google.com возвращай 255.255.255.255. Да и если есть свой DNS то и маршрутизация своя обычно есть, так что отправка серверов DoH по IP в drop решает все проблемы. В общем просто списки источников жучков и мусора станут чуть больше, а принципиально ничего не изменится.
P.S.
Снизить эффективность выкрамсывания следилок и мусора может но не досконально ибо если есть свой DNS, то вместо, например, dns.google.com возвращай 255.255.255.255. Да и если есть свой DNS то и маршрутизация своя обычно есть, так что отправка серверов DoH по IP в drop решает все проблемы. В общем просто списки источников жучков и мусора станут чуть больше, а принципиально ничего не изменится.
P.S.
ЧТД - тормоза уже на этапе mtr, а там ещё TCP, SSL, и ну его в баню.
Что значит «можно делать в сети то, что хочешь»???
Firefox либо использует DoH на 100% или не использует совсем.
Firefox либо использует DoH на 100% или не использует совсем.
Далеко не всегда получится. Например, если используется reverse proxy.
Простая ситуация — мой у моего работодателя есть сервис, который доступен глобально (с ограниченной функциональностью) и локально (из офиса — с полной функциональностью).
Если я использую DoH, то я не смогу использовать внутренние ресурсы.
Если я использую DoH, то я не смогу использовать внутренние ресурсы.
Почему? Чем это отличается от SSL VPN?
потому, что из внутренней сети я всё-равно получу внешний IP сервиса.
А это еще почему ?!
потому, что, например, Firefox будет обращаться к 1.1.1.1 и, соответственно, получит внешний IP.
потому, что, например, Firefox будет обращаться к 1.1.1.1 и, соответственно, получит внешний IP.
Если «гвоздями прибить» адреса, то так любое будет работать.
Опять же обратимся к стандарту:
3. Selection of DoH Server
…
Note that configuration might be manual (such as a user typing URI Templates in a user interface for «options») or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols). DoH servers MAY support more than one URI Template. This allows the different endpoints to have different properties, such as different authentication requirements or service-level guarantees.
Раз динамическая конфигурация поддерживается, то ее нужно просто корректно настроить, то что не доимплеменировано — дописать корректно в приложениях и серверах. Зачем ссылаться на частный случай плохой реализции?
А представьте, что вам обычный DNS даст несколько IP а не один? как-то же работает такая схема сейчас. Ничего не поменялось
А что тут сложного? Или у вас один IP в ответе или несколько. Или идете в один адрес без вариатнов или выбираете один из нескольких. Сейчас вы можете кинуть запрос на несколько DNS серверов одновременно, кто первый ответит — туда и пойдете. Какая разница кто и куда вас отправит, если вы все равно не контролируетете ответы и даже не понимаете почему именно такой ответ? От того, что ответ пришел вам в https/tls, а не «Raw» что-то поменяется принципиально?
Если сервер для DoH это что-то близкое к вам, то отвечатаю серверу DoH ДНС от CDN
А где в стандарте упомянут CDN? Они то тут вообще причем?
В стандарте написано:
3. Selection of DoH Server
The DoH client is configured with a URI Template [RFC6570], which describes how to construct the URL to use for resolution. Configuration, discovery, and updating of the URI Template is done out of band from this protocol. Note that configuration might be manual (such as a user typing URI Templates in a user interface for «options») or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols). DoH servers MAY support more than one URI Template. This allows the different endpoints to have different properties, such as different authentication requirements or service-level guarantees.
В числе первых CDN реализовали тестовую среду для этого стандарта. Пропишите, например, руками у себя OpenDns URI Template для DoH и пользуйтесь на здоровье.
Вам просто добавили еще один транспорт для DNS, оставив логику приложения «как есть».
Разве кто-то из крупных игроков нынче осуществляет геобалансировку посредством DNS? У этого подхода есть куча проблем и далеко не только те, что вы описали.
В качестве костыля, кстати, когда-то даже придумали EDNS Client Subnet, но количество серверов с его поддержкой мало.
В качестве костыля, кстати, когда-то даже придумали EDNS Client Subnet, но количество серверов с его поддержкой мало.
Имхо, данные технологии имеют смысл в мобильных устройствах и, возможно, как включаемые функции в браузерах, но ни в коем случае не как замена классическому dns на 53 порту.
В домашней сети куда более эффективнее и проще заворачивать нешифрованный dns в обычный vpn туннель.
В домашней сети куда более эффективнее и проще заворачивать нешифрованный dns в обычный vpn туннель.
А чем мобильные отличаются? Их в VPN заворачивать даже важнее, чем домашнюю сеть, потому что мобильные вечно через левые WiFi работают.
Возможно. Хотя я этого не делаю. Дома у меня интернет раздается устройствам уже пропущенный через vpn, а вне дома я им практически не пользуюсь. Vpn клиент на телефоне тоже есть, конечно, но держать его постоянно включенным это лишняя нагрузка на батарею.
Вот сейчас подумал, что включенный по умолчанию данный способ общения с dns конкретно в моей сети существенно скажется на скорости резолвинга. Потому что вместо нешифрованного запроса на локальный кеширующий dns сервер, запрос будет пересылаться куда-то в интернет, еще и с установлением tls сессии каждый раз.
В общем технологии хорошие и интересные, но это не замена dns на 53 порту.
Хорошо, наверное, их будет применять на локальном dns сервере внутри сети в качестве способа запроса к вышестоящему dns серверу, для чего раньше использовался dnscrypt.
Вот сейчас подумал, что включенный по умолчанию данный способ общения с dns конкретно в моей сети существенно скажется на скорости резолвинга. Потому что вместо нешифрованного запроса на локальный кеширующий dns сервер, запрос будет пересылаться куда-то в интернет, еще и с установлением tls сессии каждый раз.
В общем технологии хорошие и интересные, но это не замена dns на 53 порту.
Хорошо, наверное, их будет применять на локальном dns сервере внутри сети в качестве способа запроса к вышестоящему dns серверу, для чего раньше использовался dnscrypt.
Я не замечал от OpenVPN for Android никакой дополнительной нагрузки. Плюс, дополнительная фича, все мобильные устройства подключаются к домашнему VPN-серверу, что даёт им прямой доступ в домашнюю локалку — ну и дальше в инет они идут из домашней сети как все остальные домашние устройства, через второй VPN.
Что касается DoH/DoT — мне не очень нравится идея использовать для всего ресолвинга сервера одной коммерческой компании, будь то CloudFlare или Google — они гарантированно будут делать всё, чтобы воспользоваться этими данными для отслеживания и сбора информации для таргетинга рекламы. Как по мне, то VPN в другую страну, не страдающую манией фильтрации трафика, и дальше обычный DNS обеспечит большую приватность.
У меня такая же фича с доступом в домашнюю сеть, за исключением того, что все подключения происходят на адрес vps сервера. Белый ip от провайдера — сегодня это недоступная роскошь.
Я с dns все проблемы решил поднял у себя в локалке dns резолвер (не форвардер, как все обычно делают), больше года такая конфигурация у меня работает и ни одного сбоя, плюс независимость от централизованных dns серверов. Не понимаю, почему так не делают все. А раньше dnscrypt`ом пользовался, вот там периодически происходили отказы серверов и приходилось срочно искать новый.
Я с dns все проблемы решил поднял у себя в локалке dns резолвер (не форвардер, как все обычно делают), больше года такая конфигурация у меня работает и ни одного сбоя, плюс независимость от централизованных dns серверов. Не понимаю, почему так не делают все. А раньше dnscrypt`ом пользовался, вот там периодически происходили отказы серверов и приходилось срочно искать новый.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«DNS over HTTPS» оформлен в RFC 8484 — но не все им довольны