Comments 25
1. Если IP адрес целевого сервера уже определён то зачем резолвить ещё что-то? Просто его используем. И да, обращения к нему тот же провайдер легко зафиксирует/заблокирует по IP.
2. По второму протоколу можно резолвить IP адреса серверов с которых грузится весь подгружаемый контент, будь то что шрифты/стили/JS скрипты/картинки/видео. Как раз на CDN его сейчас и разворачивают.
В итоге шума будет больше, а толку-то почти нет: да, условный провайдер не подменит DNS, уже плюс. Но как отслеживал соединения так будет отслеживать.
на самом деле не подтверждают ответы DNSдолжно быть
на самом деле не проверяют ответы DNS
Я понимаю, что это перевод, однако статья является типичным FUD (то есть примером акта манипуляции и пропаганды). Компиляция случайных фактов, которые не связаны с основной темой, отсутствие технических аргументов против технологии, (ложное) апеллирование к авторитетным мнениям могут указывать на заказной характер этой статьи.
Углублюсь в детали.
DNSSEC
Это технология, которая:
- Не нашла широкого распространения. Очень малая доля доменов имеют подпись.
- Предназначена для проверки подлинности, а не обеспечения конфиденциальности запросов. К задачам, решаемым 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
В этой части я ожидал увидеть технические проблемы протокола, однако увидел только три полуправдивых утверждения, не доказывающих основной тезис. По порядку:
- Аргумент о том, что операторы сети теряют контроль над сетью и апеллирование к мнению Пола Викси. Если проследовать по ссылке, то можно заметить, что его в первую очередь не устраивает формат транспорта внутри HTTPS и вместо этого он рекомендует использовать DoT. Что же касается контроля над трафиком пользователя, то это соответствует изначальной цели протокола. Более того: в корпоративной среде, использующей MITM-фильтрацию и собственные CA-сертификаты для неё, задача фильтрации остаётся решаемой.
- Этот тезис раскрывается дальше про передачу запросов через HTTPS заявлено, что это «кошмар для встроенных приложений, а также несовместимо практически со всеми существующими типами оборудования». Это заявление не выдерживает критики, так как везде DNS обычно реализован программно, а встраиваемое оборудование может получать преимущество от DoH/DoT, настренного для всей сети. Кроме этого, в следущем абзаце зачем-то упомянут VPN и TOR, которые уж точно не представлены в массе (особенно TOR) ни на каких встраиваемых устройствах.
- Далее идёт утверждение о том, что 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 запросы становится крайне сложно. Эта информация даже сама по себе может быть полезна, не говоря уже о том если ею дополнить все остальные данные, получаемые крупными игроками.
Понятно, что защита канального уровня лучше, но она требует дополнительных усилий и тоже отнюдь не идеальна.
DOH и DOT для параноиков?
… нет никаких упоминаний виртуальных частных сетей (VPN). Они решают проблемы с шифрованием данных и DNS-запросамиВ Windows как минимум с XP/2003 при отсутствии положительного ответа в течении секунды на запрос от основного DNS-сервера на предпочтительном интерфейсе опрашиваются основные DNS-сервера всех остальных интерфейсов.
www.vpngate.net/en — отличный проект и неплохой помощник в деле отсечения длинных носов всех интересующихся.
Поделитесь кто чего включает/прописывает в OpenWRT, у кого есть роутеры.
Статья совершенно правильная, актуальная и точная.
Собственно, она в очередной раз, но в более нейтральной форме, повторят соображения, которые высказывались ведущими экспертами и разработчиками DNS ранее.
Провайдеры и производители DPI начали переживать ?
Хорошо.
DNS по HTTPS – половинчатое и неверное решение