Pull to refresh

Comments 25

UFO just landed and posted this here
А, разве, bind поддерживает DoT без дополнительных костылей? Я, наивный, unbound в качестве прослойки для bind`а прикручивал.
тупой вопрос: а нельзя использовать оба протокола? dot для начального открытия сайта и doh для продолжения работы на нем. тогда оба товарища не будут иметь полные данные об днс запросах юзера
Тут два момента:
1. Если IP адрес целевого сервера уже определён то зачем резолвить ещё что-то? Просто его используем. И да, обращения к нему тот же провайдер легко зафиксирует/заблокирует по IP.
2. По второму протоколу можно резолвить IP адреса серверов с которых грузится весь подгружаемый контент, будь то что шрифты/стили/JS скрипты/картинки/видео. Как раз на CDN его сейчас и разворачивают.

В итоге шума будет больше, а толку-то почти нет: да, условный провайдер не подменит DNS, уже плюс. Но как отслеживал соединения так будет отслеживать.
Я обращаюсь к IP CDN, на котором находятся около 1500 сайтов… Может быть надо говорить не только о шифровании DNS, но и об eSNI?
В форме сообщения об ошибке в тексте не работает кнопка «отправить», поэтому я напишу здесь. Вместо
на самом деле не подтверждают ответы DNS
должно быть
на самом деле не проверяют ответы DNS

Я понимаю, что это перевод, однако статья является типичным FUD (то есть примером акта манипуляции и пропаганды). Компиляция случайных фактов, которые не связаны с основной темой, отсутствие технических аргументов против технологии, (ложное) апеллирование к авторитетным мнениям могут указывать на заказной характер этой статьи.

Углублюсь в детали.

DNSSEC

Это технология, которая:
  1. Не нашла широкого распространения. Очень малая доля доменов имеют подпись.
  2. Предназначена для проверки подлинности, а не обеспечения конфиденциальности запросов. К задачам, решаемым DoH, не имеет никакого отношения.

Из этого упоминания автор статьи попытался наскрести повод, чтобы бросить тень сомнения на реализации DoH, предлагаемые Google и Cloudflare:
За DNS over HTTPS ратуют две крупные компании, Cloudflare и Mozilla, причём последняя даже выпустила миленький комикс, где пытается объяснить схему DoH. Неудивительно, что они совершенно не упоминают DNSSEC (несмотря на то, что её называют «критически важной» в RFC 8484), и вместо этого предлагают нечто под названием Trusted Recursive Resolver (TRR), что, по сути, представляет собой совет «использовать доверенный DNS-сервер», под которым Mozilla подразумевает Cloudflare.

Тем не менее, рекурсивные резолверы Google и CF валидируют DNSSEC. Вместе с этим, ответы DNSSEC может валидировать и DNS-форвардер на офисном или домашнем шлюзе. Стоит заметить, что технология DNSSEC имеет свои проблемы внедрения и одно из требований для полноценного обеспечения гарантий, которые может предоставить эта технология, — это обеспечение безопасного канала между DNS-клиентом и рекурсором, проверяющим подлинность DNSSEC. DoH и DoT в этом случае абсолютно уместны и делают внедрение DNSSEC практичным.

Проблема с DoH

В этой части я ожидал увидеть технические проблемы протокола, однако увидел только три полуправдивых утверждения, не доказывающих основной тезис. По порядку:
  1. Аргумент о том, что операторы сети теряют контроль над сетью и апеллирование к мнению Пола Викси. Если проследовать по ссылке, то можно заметить, что его в первую очередь не устраивает формат транспорта внутри HTTPS и вместо этого он рекомендует использовать DoT. Что же касается контроля над трафиком пользователя, то это соответствует изначальной цели протокола. Более того: в корпоративной среде, использующей MITM-фильтрацию и собственные CA-сертификаты для неё, задача фильтрации остаётся решаемой.
  2. Этот тезис раскрывается дальше про передачу запросов через HTTPS заявлено, что это «кошмар для встроенных приложений, а также несовместимо практически со всеми существующими типами оборудования». Это заявление не выдерживает критики, так как везде DNS обычно реализован программно, а встраиваемое оборудование может получать преимущество от DoH/DoT, настренного для всей сети. Кроме этого, в следущем абзаце зачем-то упомянут VPN и TOR, которые уж точно не представлены в массе (особенно TOR) ни на каких встраиваемых устройствах.
  3. Далее идёт утверждение о том, что DoT более зрелый и имеет большее распространение. Однако, DoH труднее заблокировать и он может получать преимущества в сетевом обмене, используя HTTP/2 Server Push.

Шифрование не препятствует слежке

Такое можно сказать о любом шифрованном оверлее через сеть: выходная точка видит нешифрованный трафик. Однако, это существенно сокращает возможности для слежки и в конечном итоге может определить исход доступности какого-то ресурса в условиях сетевой фильтрации. Что же касается конфиденциальности самих подключений к ресурсам — протоколы конфиденциального DNS не берутся решать эту задачу, но могут служить ценными дополнениям к другим способам обеспечения конфиденциальности.

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


DoT/DoH не препятствуют слежке, а просто подменяют одного шпиона другим, "которому можно доверять". :-D И, да, проблема ухудшения надёжности из-за централизации вполне реальна.


В целом, все доступные в данный момент "расширения" DNS толком ничего реально полезного пользователю не дают. Лучшее, что сегодня можно сделать для защиты своего трафика, включая DNS — использовать VPN/Tor, и вручную отключать DoT/DoH как только их гугл с мозиллой начинают включать по умолчанию. Либо, если концепция шпиона "которому можно доверять" не вызывает отторжения — изменять настройки DoT/DoH с гугловых на мозилловские.


С этой точки зрения статья скорее полезная, чем вредная. Да, полуправда, передёргивания и заказуха. Но это лучше, чем очередная хвалебная ода DoH.

DNSSEC не получил распространения потому, что не решает реальных проблем

Он решает реальные проблемы, но не те, о которых вы пишете. Это про удостоверение записей DNS и, следовательно, невозможность (ок — сложность) из подмены. Иными словами, про гарантию, что данные, которые опубликовал в DNS владелец, не были изменены.
Распространения же он не получил ввиду того, что сложен, замедляет процесс разрешения имён и, главное, в нём не заинтересованы крупные игроки. А для части из них, к примеру, коммерческих CA это вообще приговор, поскольку внедрение DNSSEC / DANE в популярный софт и, в первую очередь, браузеры, окончательно похоронило бы их бизнес.


В отличие от DNSSEC — DoT (и DoH) это про защиту канала, то есть про приватность.
Использование обоих инструментов совместно закрывает все актуальные проблемы нынешней DNS.

Я под "реальными" проблемами имел в виду те, с которыми реально сталкиваются обычные юзеры. Я более-менее отслеживаю новости по безопасности, и не припомню ни одной за последние несколько лет, в которой атака стала возможной именно благодаря отсутствию DNSSEC, а вот если бы он использовался — то всё, атака бы неизбежно провалилась. Можете накидать ссылок на такие случаи?


DoT (и DoH) это про защиту канала, то есть про приватность

А в чём конкретно защита? В том, что знать на какие сайты я хожу будет вместо одной мелкой организации (моего провайдера) другая крупная (гугл/cloudflare)? Защиту канала даёт VPN, и не только для DNS, а вообще для всего. Да, он её даёт только до ещё одного, сильно удалённого провайдера. Но этих удалённых "провайдеров" можно легко менять, в т.ч. автоматически (Tor). Как по мне — это заметно приватнее, чем отдать эти данные тем, кто и так уже слишком много о нас знает (считая и локального провайдера, и гугл).

Подмена ответов DNS известная как "DNS hijacking" известна и используется уже свыше двух десятков лет. Собственно, для её решения и разработали DNSSEC.
Защита в том, что отследить ваши DNS запросы становится крайне сложно. Эта информация даже сама по себе может быть полезна, не говоря уже о том если ею дополнить все остальные данные, получаемые крупными игроками.
Понятно, что защита канального уровня лучше, но она требует дополнительных усилий и тоже отнюдь не идеальна.

Некоторые провайдеры очень любят заворачивать DNS трафик на свои сервера и там их анализировать и/или изменять. Оно мне надо? Та же блокировка изначально была основана на подмене DNS ответов. DNSSEC решил бы эту проблему будь он пораспространеннее. Но мы так этого и не дождались. Зато DoT/DoH очень даже к месту пришлись и помимо достоверности (хотя она тут конечно не гарантируется) гарантируют, что ваш провайдер в запросы не заглянет.
… нет никаких упоминаний виртуальных частных сетей (VPN). Они решают проблемы с шифрованием данных и DNS-запросами
В Windows как минимум с XP/2003 при отсутствии положительного ответа в течении секунды на запрос от основного DNS-сервера на предпочтительном интерфейсе опрашиваются основные DNS-сервера всех остальных интерфейсов.
image
Проблема в том, что данный параметр как правило не используется по-умолчанию и о нём мало кто знает, а есть ещё L2TP, IPSec, Wireguard…
www.simplednscrypt.org — для linux windows macos — завороачивает весь системный траф dns на автоматом выбрираемые сервера (большая пачка, и там не только google и cloudflare конечно) — как основной протокол dnscrypt который насколько я понимаю продуман немного лучше в плане защищенности в отличие от DoH. Для большей защищенности dnscrypt запросы можно отправить в тор. Как в прочем и весь остальной трафик.

www.vpngate.net/en — отличный проект и неплохой помощник в деле отсечения длинных носов всех интересующихся.

Поделитесь кто чего включает/прописывает в OpenWRT, у кого есть роутеры.

На OpenWRT можно просто stubby установить, настроить его на DoH-сервер по своему предпочтению, а dnsmasq настроить на использование этого stubby.

DoT, он (пока) не умеет в DoH.

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

Провайдеры и производители DPI начали переживать ?


Хорошо.

Sign up to leave a comment.

Articles