Русские Блоги
В чем разница между DNS через TLS и DNS через HTTPS?
То, что звучит так просто, имеет два совершенно разных лагеря, и у каждого лагеря есть глубокая вера в то, что лучше. Лагерь одной партии более социально сознателен и более ориентирован на пользователя, их основными интересами являются конфиденциальность и права человека. Другая сторона более прагматична и даже включает в себя архитектора DNS, который считает, что сетевые администраторы должны иметь возможность видеть и анализировать действия DNS.
Прежде всего, мы понимаем, что такое DNS? Зачем ему нужен TLS или HTTPS?
Например, если вы хотите посетить веб-сайт целостности Tianwei, вы должны ввести www.itrus.cn, а затем DNS-сервер получит URL-адрес и найдет связанный с ним IP-адрес, который в нашем примере равен 123.56.97.154. Но позволять людям помнить, что это бессмысленно, поэтому URL есть везде (Google пытается устранить это).
Если вы хотите узнать IP-адрес веб-сайта, который вы посещаете, вы можете легко работать с Windows и Mac. Пользователям Windows нужно всего лишь ввести «cmd» в строку поиска, открыть командную строку и ввести:
Для пользователей Apple это проще и умнее. В строке поиска Mac введите «Сетевая утилита» и нажмите, чтобы открыть ее. Затем перейдите на вкладку Traceroute и введите доменное имя в поле трассировки.
Зачем нам нужно шифровать DNS-запросы?
Если ваша интернет-история может привести к судебному задержанию или причинению вреда, возможность сбить с толку запросы DNS может быть вопросом жизни и смерти. Это может показаться немного преувеличенным, но не требуется много исследований, чтобы понять, с какими проблемами сталкиваются обычные люди, которые были названы диссидентами из-за использования Интернета.
Для сторон, участвующих в этой дискуссии, вот почему это проблема прав человека.
Никто не думает, что DNS-запросы не должны быть зашифрованы, в центре дискуссии, как лучше всего реализовать шифрование.
Итак, в чем разница между DNS через TLS и DNS через HTTPS?
Хотя оба стандарта шифруют DNS-запросы, между ними есть некоторые важные различия. Инженерная рабочая группа по Интернету (IETF) определяет DNS по HTTPS как RFC 8484 и DNS по TLS как RFC 7858 и RFC 8310.
Посредством шифрования и аутентификации TLS DNS поверх TLS использует TCP в качестве основного протокола соединения. DNS через HTTPS использует HTTPS и HTTP / 2 для подключения.
Это важное отличие, поскольку оно влияет на используемые порты. DNS over TLS имеет собственный порт 853. DNS через HTTPS использует порт 443, который является стандартным портом для трафика HTTPS.
Хотя выделенный порт звучит как преимущество, в некоторых случаях это на самом деле наоборот. DNS over HTTPS может быть скрыт в другом зашифрованном трафике, но все запросы DNS over TLS поступают с уникального порта, и любой на сетевом уровне может легко их увидеть и даже заблокировать. Конечно, независимо от содержимого или ответа, сам запрос зашифрован. Таким образом, вы не знаете, что запрашивается, но они знают, что вы используете DNS поверх TLS.
Иногда лучший выбор не согласуется с качественной точки зрения, с точки зрения прав человека и даже морали. Для многих людей, стоящих в лагере DNS over TLS, это не имеет ничего общего с проблемами конфиденциальности в реальном мире, но потому, что они думают, что DNS через HTTPS является стандартом более низкого уровня, чем DNS через TLS.
Совет по безопасности
1. Крупные предприятия, а также отдельные пользователи регулярно проверяют и своевременно исправляют системные исправления и исправления важного программного обеспечения;
2. Разверните SSL-сертификат для корпоративного веб-сайта как можно скорее. После развертывания SSL-сертификата вы можете проверить подлинную идентификацию веб-сайта, проверив информацию о SSL-сертификате в HTTPS, расширив возможности пользователя для определения правильной информации о веб-сайте и не допустив обмана пользователя, щелкнув поддельный веб-сайт. Через уровень шифрования SSL передаваемые данные также могут быть зашифрованы и расшифрованы для обеспечения безопасности данных во время передачи и для обеспечения конфиденциальности и целостности данных.
HTTPS является наиболее безопасным решением в современной архитектуре и в наибольшей степени предотвращает атаки типа «человек посередине». При развертывании SSL-сертификатов вы должны выбрать надежную организацию CA. Лучше всего пройти международную сертификацию WEBTRUST, такую как GDCA в эпоху Шуань. С самыми безопасными решениями и профессиональными пользователями команды технической поддержки, пользователи эпохи Шуан предоставляют самую авторитетную услугу аутентификации и самую безопасную гарантию аутентификации. С помощью богатой профессиональной команды сервисной поддержки, которая реагирует и решает различные сложные и неожиданные ситуации, она может предоставить пользователям 7 * 24 один на один сервис и техническую поддержку. При необходимости вы можете проконсультироваться со службой поддержки на официальном сайте.
Минимизация рисков использования DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH)
Защита от DoH и DoT
Контролируете ли вы свой DNS трафик? Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Однако, одной из областей, которой часто не уделяется должного внимания, является DNS.
Хорошим обзором рисков, которые приносит DNS является презентация Verisign на конференции Infosecurity.
31% обследованных классов программ-вымогателей использовали DNS для обмена ключами. Выводы исследования
31% обследованных классов программ-вымогателей использовали DNS для обмена ключами.
Проблема серьезная. По данным исследовательской лаборатории Palo Alto Networks Unit 42, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW.
Появились новые протоколы для DNS, направленные на повышение конфиденциальности DNS соединений. Они активно поддерживаются ведущими поставщиками браузеров и другими поставщиками программного обеспечения. Скоро в корпоративных сетях начнется рост зашифрованного DNS-трафика. Зашифрованный трафик DNS, который не анализируется средствами должным образом и разрешен, представляет угрозу безопасности для компании. Например, такой угрозой являются криптолокеры, которые используют DNS для обмена ключами шифрования. Атакующие сейчас требуют выкуп в несколько миллионов долларов за восстановление доступа к вашим данным. В компании Garmin, например, заплатили 10 миллионов долларов.
При правильной настройке NGFW могут запрещать или защищать использование DNS-over-TLS (DoT) и могут использоваться для запрета использования DNS-over-HTTPS (DoH), что позволяет анализировать весь трафик DNS в вашей сети.
Что такое зашифрованный DNS?
Система доменных имен (DNS) преобразует удобочитаемые человеку доменные имена (например, адрес www.paloaltonetworks.com ) в IP-адреса (например, в 34.107.151.202). Когда пользователь вводит доменное имя в веб-браузере, браузер отправляет DNS-запрос на DNS-сервер, запрашивая IP-адрес, связанный с этим доменным именем. В ответ DNS-сервер возвращает IP-адрес, который будет использовать этот браузер.
Запросы и ответы DNS пересылаются по сети в виде обычного текста в незашифрованном виде, что делает его уязвимым для шпионажа или изменения ответа и перенаправления браузера на вредоносные сервера. Шифрование DNS затрудняет отслеживание DNS-запросов или их изменение во время передачи. Шифрование DNS запросов и ответов защищает вас от атаки Man-in-the-Middle, выполняя при этом те же функции, что и традиционный протокол DNS (система доменных имен) с открытым текстом.
За последние несколько лет были внедрены два протокола шифрования DNS:
Эти протоколы имеют одну общую черту: намеренно прячут DNS-запросы от любого перехвата. и от безопасников организации в том числе. Протоколы в основном используют протокол TLS (Transport Layer Security) для установления зашифрованного соединения между клиентом, выполняющим запросы, и сервером, разрешающим запросы DNS, через порт, который обычно не используется для трафика DNS.
Конфиденциальность запросов DNS является большим плюсом этих протоколов. Однако, они создают проблемы безопасникам, которые должны следить за сетевым трафиком и обнаруживать и блокировать вредоносные соединения. Поскольку протоколы различаются по своей реализации, методы анализа будут отличаться у DoH и DoT.
DNS over HTTPS (DoH)
DoH использует хорошо известный порт 443 для HTTPS, для которого в RFC специально указано, что задача состоит в том, чтобы «смешать трафик DoH с другим трафиком HTTPS в одном и том же соединении», «затруднить анализ трафика DNS» и, таким образом, обойти меры корпоративного контроля ( RFC 8484 DoH, раздел 8.1 ). Протокол DoH использует шифрование TLS и синтаксис запросов, предоставляемый общими стандартами HTTPS и HTTP/2, добавляя запросы и ответы DNS поверх стандартных запросов HTTP.
Риски, связанные с DoH
Если вы не можете отличить обычный HTTPS-трафик от запросов DoH, то приложения внутри вашей организации могут (и будут) обходить локальные настройки DNS, перенаправляя запросы на сторонние сервера отвечающие на запросы DoH, что обходит любой мониторинг, то есть уничтожает возможность контроля за DNS трафиком. В идеале вы должны контролировать DoH используя функции расшифрования HTTPS.
Обеспечение видимости и контроля трафика DoH
В качестве наилучшего решения для контроля DoH мы рекомендуем настроить в NGFW расшифровку трафика HTTPS и блокировку трафика DoH (название приложения: dns-over-https).
Во-первых, убедитесь, что NGFW настроен для расшифровки HTTPS, согласно руководству по лучшим методам расшифровки.
Во-вторых, создайте правило для трафика приложения «dns-over-https», как показано ниже:
Правило Palo Alto Networks NGFW для блокировки DNS-over-HTTPS
В качестве промежуточной альтернативы (если ваша организация не полностью реализовала расшифрование HTTPS) NGFW можно настроить для применения действия «запретить» к идентификатору приложения «dns-over-https», но эффект будет ограничен блокировкой определенных хорошо известных серверов DoH по их доменному имени, так как без расшифрования HTTPS трафик DoH не может быть полностью проверен (см. Applipedia от Palo Alto Networks и выполните поиск по фразе «dns-over-https»).
DNS over TLS (DoT)
Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 ( RFC 7858, раздел 6 ). Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.
Риски, связанные с DoT
Обеспечение видимости и контроля трафика DoT
В качестве наилучшей методики контроля за DoT мы рекомендуем любое из вышеперечисленного, исходя из требований вашей организации:
Настройте NGFW для расшифрования всего трафика для порта назначения 853. Благодаря расшифрованию трафика, DoT будет отображаться как приложение DNS, к которому вы можете применить любое действие, например, включить подписку Palo Alto Networks DNS Security для контроля DGA доменов или уже имеющийся DNS Sinkholing и anti-spyware.
В качестве альтернативы можно полностью заблокировать движком App-ID трафик ‘dns-over-tls’ через порт 853. Обычно он заблокирован по умолчанию, никаких действий не требуется (если вы специально не разрешили приложение ‘dns-over-tls’ или трафик через порт 853).
Битва за данные пользователей: зачем нужно шифровать DNS-запросы
Специалисты по обеспечению конфиденциальности и безопасности находятся в центре публичной борьбы за будущее шифрования трафика в интернете. В сентябре кабельные компании и другие представители телекоммуникационной отрасли в США направили в Конгресс письмо с протестом против планов Google по шифрованию трафика системы доменных имен (DNS) в браузере. В этом месяце Mozilla отправила в Конгресс собственное письмо, в котором просила законодателей не рассматривать этот протест, поскольку он основан на «фактических неточностях».
Речь идет о том, как следует шифровать DNS-трафик — сетевые запросы, которые преобразуют понятные людям доменные имена (адреса сайтов) в IP-адреса серверов. Когда пользователь вводит доменное имя в браузере, тот запрашивает у ближайшего указанного в настройках DNS-сервера IP-адрес, связанный с этим доменным именем.
По умолчанию эти запросы и ответы сервера отправляются по сети в виде обычного текста, что означает, что кто-то может перехватить их и перенаправить пользователя в другое место назначения. Простые текстовые DNS-запросы также позволяют администраторам сети видеть, на какие сайты заходят пользователи: фактические действия могут быть зашифрованы, но и такие знания могут предоставить ценную информацию, например, для рекламодателей. 
Шифрование DNS гарантирует, что «браузер общается с тем, с чем вы хотите взаимодействовать, а не с тем, куда вас зовут вредоносные программы», — говорит Тим Эйприл, главный архитектор сетевой компании Akamai.
Никто не спорит с тем, что DNS должен быть зашифрован. Третьи стороны не должны иметь возможность перехватывать и перенаправлять пользователей на сторонние сайты, на которых могут быть размещены вредоносные программы или поддельные формы авторизации. Разногласия заключатся лишь в том, как это шифрование должно быть сделано.
Существует два варианта: так называемые DNS поверх TLS и DNS поверх HTTPS. Первый подчеркивает безопасность и дает администраторам сетей больше контроля, а второй подчеркивает конфиденциальность пользователей. С точки зрения удобства использования пользователи не заметят различий с любым из этих подходов, чего нельзя сказать о системных администраторах.
Два способа шифрования
Современные сети полагаются на протокол защиты транспортного уровня (TLS) для безопасного обмена данными, например, для просмотра веб-страниц, передачи файлов, VPN-подключений, сеансов удаленного рабочего стола и передачи голоса по IP-телефонии. Одна сторона соединения, обычно сервер, имеет сертификат с цифровой подписью, выданный доверенным центром сертификации. Другая сторона соединения, обычно клиент, использует сертификаты для проверки того, с кем он обменивается данными. 
Поскольку протокол TLS уже широко используется для обеспечения конфиденциальности, аутентификации и целостности данных, расширение протокола для работы с DNS является вполне логичным. DNS поверх TLS (IETF RFC 7858) определяет, как DNS-пакеты будут шифроваться с помощью TLS и передаваться по широко используемому протоколу управления передачей (TCP).
По умолчанию DNS проходит через порт 53 по протоколу TCP или UDP. При использовании DNS поверх TLS все зашифрованные пакеты отправляются через порт 853. Большинство общедоступных DNS-серверов, включая Cloudflare, Quad9 и Google, уже поддерживают DNS поверх TLS, и компании, использующие собственную DNS-инфраструктуру, также могут использовать такое шифрование.
Google включил поддержку DNS поверх TLS в Android Pie (Android 9), чтобы пользователи могли настраивать шифрование DNS как для Wi-Fi, так и для мобильной сети, и многие приложения и устройства уже умеют работать с этой опцией.
«Мы решили проблему, добавив DNS к TLS», — сказал Пол Викси, изобретатель DNS и генеральный директор Farsight Security. Он также признает, что такое решение не является «веб-дружественным» в том смысле, что нет простого пользовательского интерфейса для включения этой функции.
DNS поверх HTTPS (IETF RFC8484) в значительной степени разработан с оглядкой на принципы работы современного интернета, поскольку он вбрасывает все пакеты данных в поток HTTPS вместе с другим зашифрованным веб-трафиком. В отличие от своего конкурента, DNS поверх HTTPS не шифрует отдельные запросы, а вместо этого пропускает их через зашифрованный туннель между клиентом и сервером. 
Поскольку соединение использует HTTPS и HTTP/2, все пакеты выглядят одинаково. Любой, кто отслеживает порт 443 — стандартный порт HTTPS — не сможет идентифицировать DNS-запросы из всего остального веб-трафика.
Плюсы и минусы каждого подхода
Для сторонников конфиденциальности DNS через TLS недостаточно хорош, потому что любой, кто контролирует сеть, будет знать, что любая активность на 853-ем порту связана с этим DNS. Хотя наблюдатель не будет знать фактическое содержание запроса, поскольку и ответ, и запрос зашифрованы, тот факт, что сетевой администратор или провайдер будут знать, что есть такая активность, уже может привести к последствиям для пользователя (в худшем случае этот порт может быть вообще закрыт). Хотя DNS поверх TLS безопасен, он не так удобен с точки зрения конфиденциальности, как DNS поверх HTTPS.
Еще один недостаток DNS поверх TLS заключается в том, что разработчикам программного обеспечения и производителям устройств необходимо внести изменения, чтобы их приложения и оборудование поддерживали этот протокол. И если такой поддержки нет, даже если указанный DNS-сервер может работать с таким шифрованием, оно не будет защищать данные пользователя.
DNS поверх HTTPS более демократичен, поскольку любой пользователь, использующий поддерживаемый веб-браузер, автоматически получает шифрование DNS. DNS поверх HTTPS лишает любые третьи стороны — в том числе поставщиков интернет-услуг и правительственные учреждения — возможности просматривать информацию о том, какие сайты посещает пользователь. Это именно то, что хотят защитники конфиденциальности, но это противоположно тому, что нужно сетевым администраторам.
Конфиденциальность против безопасности
DNS поверх HTTPS возводит конфиденциальность в абсолют, но создатели приложений родительского контроля, антивирусных программ, корпоративных брандмауэров и других сетевых инструментов не разделяют эту идеологию. Включение DNS поверх HTTPS по умолчанию в веб-браузере означает, что все DNS-запросы передаются на указанный DNS-сервер, который может не являться собственным DNS-сервером организации или провайдера.
Mozilla объявила, что DNS поверх HTTPS будет использоваться по умолчанию для пользователей Firefox в Соединенных Штатах, и это изменение в настоящее время активно внедряется. Firefox автоматически передает весь DNS-трафик популярному серверу Cloudflare 1.1.1.1 и игнорирует существующие настройки DNS пользователя. Это обходит все связанные с DNS сетевые правила фильтрации, в том числе позволяет попасть на сайты, доступ к которым блокируется по DNS.
Google также включил DNS поверх HTTPS для пользователей Chrome, но тут его принцип работы немного отличается, поскольку браузер по умолчанию использует DNS поверх HTTPS только в том случае, если у пользователя есть служба, совместимая с DNS поверх HTTPS.
Microsoft, как обычно, хочет усидеть на двух стульях одновременно: с одной стороны, компания планирует поддерживать DNS поверх HTTPS в Windows, с другой — хочет дать системным администраторам некоторый контроль.
Эйприл считает, что шифрование DNS — это «разумное ограничения доступа» к плохим ресурсам, но с ним нужно быть осторожнее. Провайдеры частенько блокируют имена хостов, используемые Wannacry и другими вредоносными программами, и временами перенаправляют пользователей, пытающихся получить доступ к вредоносным или заблокированным сайтам. Администраторы общедоступных сетей Wi-Fi модифицируют DNS-запросы, чтобы сначала загружалась страница авторизации для новых пользователей. DNS поверх HTTPS ломает все эти настройки.
Отчасти поэтому Mozilla не включает DNS поверх HTTPS для пользователей Firefox в Соединенном Королевстве, так как там закон требует от интернет-провайдеров блокировать доступ к нелегальным веб-сайтам, таким как те, которые связаны с детской порнографией. 
DNS поверх HTTPS против DNS поверх TLS — это еще одна разновидность борьбы за данные о просмотре веб-страниц пользователем и за то, кто получит доступ к ним. DNS-запросы от Firefox будут отправляться в Cloudflare, что означает, что Cloudflare будет иметь доступ к огромному количеству данных DNS. По словам Викси, технологические компании, которые управляют централизованными DNS-серверами, такие как Cloudflare и Google, в конечном итоге получат выгоду от DNS поверх HTTPS, поскольку именно они будут получать информацию о том, что люди просматривают в интернете.
Сторонники конфиденциальности считают, что не провайдеры, а сами пользователи должны отвечать за то, как они попадают на сайты в интернете. Но решение Mozilla заставляет пользователей Firefox использовать Cloudflare независимо от их собственных предпочтений.
Большинство пользователей не заметят никакой разницы, когда шифрованный DNS станет стандартным, что уже произошло для пользователей Chrome. Для компаний и интернет-провайдеров социально-сознательный, ориентированный на пользователя подход вынуждает идти на компромисс: ценой повышения конфиденциальности является снижение безопасности.
Реальность современного интернета заключается в том, что интернет-провайдеры и компании играют определенную роль в предотвращении угроз для пользователей. В идеале веб-браузеры должны позволять пользователям выбирать, следует ли использовать DNS поверх TLS или DNS поверх HTTPS, а также предоставлять пользователям возможность контролировать, какого поставщика DNS использовать.
Глубокий в-DoH. Разбираемся, как работает DNS over HTTPS и кому (не) выгодно его внедрение
Содержание статьи
Шаткая скрепа DNS
Для порядка и связности изложения кратко вспомним основные понятия. Система доменных имен DNS — одна из технологий, лежащих в самой основе современного интернета. С ее помощью соотносятся числовые IP-адреса и более удобные для человека доменные имена. Она построена по принципу иерархического взаимодействия DNS-серверов.
Важный момент: разрабатывалась эта система еще в 1983 году, и поэтому у нее есть некоторые проблемы с безопасностью. Ведь интернет тогда, как известно, был сетью, которая связывала американские научные и военные учреждения, и подключать к ней кого попало не планировалось.
Если вкратце, то корень проблемы в том, что базовая система DNS принимает и передает любые запросы, поступающие в нее. Как во многих других решениях, которые появились на заре интернета, защиты от злонамеренного использования здесь нет. В те времена считалось, что главное — это простота и масштабируемость.
В результате появились разные методы атак на DNS-серверы (например, отравление кеша DNS или перехват DNS). Результат таких атак — перенаправление клиентских браузеров куда-то, куда пользователи попадать не собирались.
Для борьбы с этими бедами Инженерный совет интернета разработал набор расширений DNSSEC, который добавил к DNS-запросам подпись-аутентификацию на основе криптографии с открытым ключом. Но разрабатывался этот набор расширений очень долго. Проблема стала очевидной еще в начале девяностых, направление работы над проблемой определили к 1993 году, первую версию DNSSEC подготовили к 1997 году, попытались внедрить, стали вносить изменения.
Если хочешь подробнее разобраться, от каких угроз DNSSEC должен был защитить DNS, то можешь почитать доклад об анализе угроз того самого Инженерного совета интернета от 2004 года. Как пишут его авторы, спустя десять лет после начала работ настало время отчитаться о том, с какими проблемами и как именно мы собираемся бороться.
Но DNSSEC решает только часть проблемы — он гарантирует аутентичность и целостность данных, но не их приватность. В борьбе за эту цель логичным средством выступает шифрование. Вопрос в том, как именно его реализовать.
Варианты шифрования
Несколько групп разработчиков предложили свои варианты технологических решений. Среди них есть те, которые используют оригинальные способы шифрования, например DNSCrypt или DNSCurve, в котором применяется шифрование с использованием эллиптических кривых. Но решения, оказавшиеся в итоге более популярными, опираются на широко распространенный протокол безопасности TLS. Такими решениями являются DoT (DNS over TLS) и DoH, основной предмет этой статьи.
DoT, как и следует из его названия, использует для зашифрованной передачи DNS-запросов сам протокол TLS. Это влечет за собой смену основных портов и протоколов — вместо UDP по порту 53 используется TCP по порту 853.
DoH устроен иначе и по-другому использует TLS. В DoH TLS-шифрование применяется на уровне протокола HTTPS, с использованием HTTPS-запросов и обращением к HTTP-портам DNS-сервера.
Звучит сложновато? Ян Шауман рассказывает об этом очень точно и доходчиво:
Поскольку HTTPS использует TLS, можно было бы позанудствовать и подоказывать, что технически DoH — это тоже DNS через TLS. Но это было бы неверно. DoT отправляет запросы базового протокола DNS через TLS-соединение на отдельном выделенном порте. DoH использует протокол HTTP на уровне протокола прикладного уровня (HTTP application layer protocol), чтобы отправлять запросы на HTTPS-порт сервера, используя и включая все элементы обычных сообщений HTTP.
DoHодим до сути
Здесь резонно задаться вопросом: а в чем вообще тут может быть проблема? Чем больше безопасности, тем лучше, разве не так?
Ответ на этот вопрос лежит в нюансах выбранных решений, их сильных и слабых сторонах. А именно в том, как новая технология взаимодействует с разными участниками системы DNS, кого из них ее разработчики считают условно заслуживающими доверия, а кого — источниками угрозы. И речь сейчас даже не о хакерах-злоумышленниках, имеющих откровенно преступные цели.
Речь о том, что между пользовательским устройством и конечным сайтом находятся посредники. Администратор сети, файрвол, провайдер интернета — все они могут в своих интересах взаимодействовать с системой DNS, задавая своим резолверам имен DNS настройки того, какие запросы отслеживать, блокировать, модифицировать. Так можно встраивать рекламу, отсекать вредоносный контент, не пускать на определенные ресурсы.
Путь запроса от клиента до сервера может проходить через множество резолверов
DoT, работая через TLS с его системой сертификатов доверия, точно так же нуждается в DNS-резолвере, которому он сможет доверять. Присутствует гибкая возможность настройки списка доверенных резолверов, возможность централизованного изменения настроек в предварительно доверенной (например, корпоративной) среде, а также возможность переключаться обратно на базовый DNS, если с новой версией возникнут проблемы.
Поскольку для DoT используется новый, выделенный порт, возможно заметить передаваемый трафик и наблюдать за его объемами, шифрование этому никак не помешает. При желании можно даже заблокировать его вовсе.
В общем, DoT нужно грамотно настроить, но зато он содержит некоторые крайне полезные для системных администраторов и сетевых инженеров функции. Поэтому многие из профессионалов и хвалят за это DoT.
С DoH история другая. Эта технология разрабатывалась с расчетом на пользовательские приложения, а именно — браузеры. Это ключевая деталь во всей этой истории. Означает она вот что. При использовании DoH весь трафик, который не относится к браузерам, идет через базовый DNS, но браузерный трафик при этом обходит любые настройки DNS — на уровне операционной системы, локальной сети, провайдера — и, минуя промежуточные этапы, по HTTPS попадает сразу к поддерживающему DoH резолверу DNS.
И к этой схеме есть ряд серьезных вопросов.
Коварные злодеи и теории заговора
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
