-

2019-09-27 00:32:39

kostikov@zotum.net

Очень хорошая статья почему DNS-over-HTTPS может работать в обратную сторону и о других связанных проблемах безопасности.

Centralised DoH is bad for privacy, in 2019 and beyond

Recently, Mozilla announced it would be moving Firefox DNS lookups to Cloudflare by default, for its American audience. There will be a notification about this for existing users, at which point th…

#DNS #TLS #HTTPS #security #privacy #censorship

show all 29 comments

2019-09-27 17:31:05

Alexander

alexander@deko.cloud

Если кратко, то все централизованное плохо. Но кто мешает сделать это децентрализованным?

2019-09-27 17:37:32

Max Kostikov

kostikov@zotum.net

@Alexander

Но кто мешает сделать это децентрализованным?

Производители браузеров (и проч.) и их бизнес-интересы.
Других причин не развивать DoT, который не приводит к отказу от децентрализации (для клиента), педалируя при этом DoH, я не вижу.

2019-09-27 18:07:49

Alexander

alexander@deko.cloud

Производители браузеров пока не обладают монополией на DNS :)

Но да, текущая тенденция мне не нравится. Думаю, это всё же переходный период.

2019-09-27 18:14:09

Alexander

alexander@deko.cloud

На всякий случай (для залётных комментаторов) добавлю: для пользователей разницы между DoT и DoH нет.

И то, и другое может быть децентрализовано или наоборот завязано на конкретного провайдера средствами ПО.

2019-09-27 18:20:31

Max Kostikov

kostikov@zotum.net

@Alexander Разница есть. Если DoT получит распространение и, следовательно, приедет на каждое устройство в составе локального ресольвера, тот централизации не будет. То есть её можно устроить через форвадинг к "правильным" серверам, но в целом нет. В то время как DoH изначально предполагает привязку клиента к конкретному источнику данных DNS.

2019-09-27 18:23:29

Max Kostikov

kostikov@zotum.net

@Alexander

Но да, текущая тенденция мне не нравится. Думаю, это всё же переходный период.

Я думаю будут топить за DoH изо всех утюгов тормозя внедрение DoT. Как, собственно, уже было сделано с внедрением DNSSEC/DANE, который является явной и прямой угрозой, например, для бизнеса (функций контроля и мониторинга) выдающих TLS-сертификаты CA.

2019-09-27 18:33:45

Alexander

alexander@deko.cloud

Скорей всего, это же возможность заработать. Но в итоге всё равно придет к децентрализации. Если же не придёт, что тут сказать. Не заслуживаем.

И для нас и многих других это всяко лучше обычного DNS.

2019-09-27 18:36:25

Alexander

alexander@deko.cloud

В то время как DoH изначально предполагает привязку клиента к конкретному источнику данных DNS.

На совсем понятно почему. Это лишь интерфейс. Точно так же появится множество серверов, как публичных, так и частных.

2019-09-27 20:46:56

Max Kostikov

kostikov@zotum.net

@Alexander

На совсем понятно почему. Это лишь интерфейс

Сейчас попробую объяснить. DoH решает проблему шифрования DNS трафика для клиента, который использует HTTP протокол. DoT решает проблему шифрования DNS трафика на уровне обмена как между серверами, так и клиентами. В последнем случае шифровать что-то между клиентом и DNS сервером не надо, поскольку он будет обращаться к локальному DNS резольверу, который дальше уже будет вести шифрованный обмен с остальной сетью серверов. Децентрализованной и распределённой. То есть клиент будет получать ответы не от одного источника, как в случае с DoH, а рекурсивно от ответственных за конкретные домены DNS серверов.
При этом очевидно, что на DNS серверах - авторитативных и резольверах, DoH вместе с его промежуточной прослойкой HTTPS нафиг не упёрся, и достаточно прямой инкапсуляции стандартных DNS пакетов (wire format) в TLS что и называется DoT.

2019-09-27 21:42:35

Alexander

alexander@deko.cloud

@Max Kostikov, вероятно, я что-то не до конца понимаю, но, как по мне, особой разницы нет.

Смотрим с точки зрения клиента. Он в общем случае обращается к одному (двум, трём) серверам имён. Как именно он обращается - DoT, DoH или ещё что, не суть важно. Если последняя миля прикрыта, то задача так или иначе решена. Причём у разных инструментов разные преимущества, например, DoH с большей вероятностью пробьёт файрвол, так же его проще реализовать для клиентов, не имеющих административных прав на своих устройствах. Думаю, у DoH выше устойчивость к госцензуре, особенно, если такой резольвер повесить на сайт с котами.

После того, как клиент достучался до своего сервера имён, тот уже может работать децентрализованно. А может и не работать.

В любом случае, что там происходит дальше по сети, обычно простым людям не очень интересно, но туда, я уверен, DoT придёт неизбежно. Там я согласен, никакие костыли не нужны.

Идея же иметь каждому клиенту полноценный резольвер... ну не знаю :)

2019-09-27 22:24:43

Max Kostikov

kostikov@zotum.net

@Alexander

Смотрим с точки зрения клиента

С точки зрения клиента в случае если есть форвардинг к конкретному DNS ресольверу (а в DoH он есть всегда), принципиально, безразлично.
Тезис о, якобы, большей устойчивости DoH к фильтрации тоже не выдерживает критики. Во-первых, ничто не мешает DoT обращаться по тому же 443 порту, что, кстати, многие публичные DNS сервисы реализуют наряду со стандартным 853 портом. И, во-вторых, если говорить о фильтрации по имени хоста / IP, то разницы между стойкостью DoH и DoT и вовсе никакой нет.

2019-09-27 22:29:36

Max Kostikov

kostikov@zotum.net

@Alexander

Идея же иметь каждому клиенту полноценный резольвер...

На самом деле, тем более если не заморачиваться с кэшированием и префетчингом данных с истекающим сроком действия, задача тривиальная. Вполне реализуемо на уровне системной getaddrinfo() и иже с ней.

2019-09-27 22:59:39

Alexander

alexander@deko.cloud

Ну, если DoT вешать на 443 порт, то между ними и разницы особенной нет для конечного пользователя :)

Как по мне, основная разница сейчас в том, что DoH планируется внедрять на уровне отдельных приложений. а DoT обычно работает на уровне системы, хотя понятно, что можно и наоборот.

2019-09-28 10:43:48

Sinaps

sinaps@diasp.org

каждому клиенту полноценный резольвер…

Прекрасная идея. Изображение / фотография

2019-09-28 11:55:46

Alexander

alexander@deko.cloud

Прекрасная идея.

Ну, такое :) На хороших линках нормально, наверное, но быстродействие пострадает.

Я даже в условиях небольшого офиса замечал, что хороший провайдеровский DNS работает быстрее, чем собственный.

2019-09-28 12:12:01

Max Kostikov

kostikov@zotum.net

@Alexander

Ну, такое :) На хороших линках нормально, наверное, но быстродействие пострадает.

Если не кэшировать, то да, идея так себе. Но кэширующий локальный резольвер входит в состав многих популярных систем, начиная с Windows. Во FreeBSD и производных в составе системы есть Unbound, пожалуй, лучший рекурсивный резольвер.

2019-09-28 13:29:26

Sinaps

sinaps@diasp.org

хороший провайдеровский DNS работает быстрее, чем собственный

Шейпинг, приоритет DNS-трафика? (Кроме кэшироания.)

Во FreeBSD и производных в составе системы есть Unbound

Можно и из портов, тот что поновее.

2019-09-28 13:36:47

Alexander

alexander@deko.cloud

Шейпинг, приоритет DNS-трафика?

Думаю, именно кэширование.

То есть, если взять офис голов этак на 100 со своим почтовиком с антиспамом, прокси и так далее, то свой DNS у меня там работал заметно (некритично, но заметно) медленнее, чем он же, но с форвардингом запросов на сервер провайдера или даже 8.8.8.8.

Но при условии, что провайдер крупный и хороший. Если нет, то наоборот :)

И да, клиенты - Винда. То есть, в обоих случаях имеют свой локальный кэш DNS, кэш браузера.

2019-09-28 13:42:52

Alexander

alexander@deko.cloud

Недостатки, конечно, тоже есть. Чуть больше практическая вероятность отказа, могут быть задержки при обновлении данных.

2019-09-28 13:44:39

Max Kostikov

kostikov@zotum.net

@Alexander

То есть, если взять офис голов этак на 100 со своим почтовиком с антиспамом, прокси и так далее, то свой DNS у меня там работал заметно (некритично, но заметно) медленнее, чем он же, но с форвардингом запросов на сервер провайдера или даже 8.8.8.8.

Если локальный сервер кэширующий, то это очень странно. Мой опыт показывает что локальный кэширующий сервер отвечает быстрее за исключением первого запроса, когда ещё кэш пуст, но и то не факт в связи с тем что нет гарантий наличия в провайдерском DNS того же закэшированного запроса.
Я даже на мало-мальски нагруженных почтовых серверах всегда поднимаю локальный кэширующий DNS резольвер потому что это существенно ускоряет обработку трафика что видно даже невооружённым глазом.

2019-09-28 13:58:59

Sinaps

sinaps@diasp.org

локальный кэширующий сервер отвечает быстрее за исключением первого запроса

Да. drill google.com @127.0.0.1 ;; Query time: 0 msec drill google.com @8.8.8.8 ;; Query time: 86 msec

2019-09-28 16:21:06

Alexander

alexander@deko.cloud

Что на исправной системе запрос из кэша будет всегда быстрее - это понятно. Но локальный кэш надо ещё прогреть, а в небольшой сети, по всей видимости, и кэш уровня ЛВС не всегда даёт достаточно попаданий.

А вот у сервера провайдера кэш прогрет очень хорошо, да ещё и с учётом местной специфики. У какого-нибудь 1.1.1.1 - тоже.

Впрочем, у меня это несколько устаревший опыт, вероятно, на современной сети эта разница будет неощутима вообще никак.

2019-09-29 15:06:08

Sinaps

sinaps@diasp.org

в случае если есть форвардинг к конкретному DNS ресольверу

А если его нет, то ssl-upstream: yes у меня заканчивается надписью в логе error: ssl handshake failed crypto error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol и ответом сервера на любой запрос Error: error sending query: Could not send or receive, because of network error Как запустить DoT? Изображение / фотография

2019-09-29 15:40:09

Max Kostikov

kostikov@zotum.net

@Sinaps Ну правильно заканчивается. Вы же не думаете что все DNS серверы поддерживают DoT?
Такое, надеюсь, когда-то случится, но пока вам только форвадить куда-то, если хотите избежать цензурирования и отслеживания.
У меня вот всё (и DoT и DoH) идёт к собственной VPS'ке, где уже другой Unbound разруливает по стандартному DNS протоколу.

2019-09-29 15:50:12

Sinaps

sinaps@diasp.org

Вы же не думаете что все DNS серверы поддерживают DoT?

Я надеялся что да, но если нет, то причины такой ошибки конечно понятны. Спасибо за объяснения.

2019-09-29 19:09:37

Alexander

alexander@deko.cloud

Так вот чего мне для счастья не хватало -- своего DNS. Но хочется на роутере, чтоб для всей сети, а Микротик не поддерживает :(

Попробую через костыль - настроить редирект всего DNS-трафика в VPN.

2019-09-29 19:24:06

Max Kostikov

kostikov@zotum.net

@Alexander

Но хочется на роутере, чтоб для всей сети

Так вы пропишите в DNS которые ваш DHCP выдаёт свои IP, например на локальный DNS резольвер. А с него форвардинг куда-нибудь через DoT. Или сразу весь трафик на роутере заворачивать в VPN. Это ещё проще. Тогда и насчёт DNS трафика можно не особенно беспокоиться.

2019-09-29 19:49:46

Sinaps

sinaps@diasp.org

а Микротик не поддерживает :(

Что не поддерживает mikrotik?

2019-09-29 20:19:10

Alexander

alexander@deko.cloud

Так вы пропишите в DNS которые ваш DHCP выдаёт свои IP, например на локальный DNS резольвер.

@Max Kostikov Для этого надо ещё его завести, у меня сейчас дома нет постоянно работающих хостов. Наверное, надо будет разориться на какой-нибудь Pi.

@Sinaps защищенный DNS не поддержиивается Микротиком (пока?) ни по какой технологиии штатно. Вроде, народ что-то там мудрит на рутованных устройствах. То есть, просто взять и направить внутренний резольвер Микротика на защищенный DNS сервер нельзя. А было бы здорово.