Dns resolution daemon что это

Обновлено: 06.07.2024

Знаете ли вы, что можно повысить производительность и безопасность работы в Интернете, выбрав альтернативный преобразователь DNS? Хорошей новостью является то, что это бесплатно, а настройка занимает около минуты вашего времени.

Что такое DNS преобразователь

Система доменных имен (DNS) может часто встречаться в разговоре сетевого администратора, но средний пользователь, вероятно, не знает или не заботится о том, что такое DNS или что он для него делает.

DNS – это «клей», который связывает доменные имена и IP-адреса вместе. Если у вас есть сервер и вы хотите, чтобы люди могли на него заходить, используя доменное имя, вы можете заплатить пошлину и зарегистрировать свое уникальное доменное имя (если оно доступно) у интернет-регистратора. Если у вас есть доменное имя, связанное с IP-адресом вашего сервера, тогда люди могут перейти на ваш сайт, используя ваше доменное имя вместо того, чтобы вводить IP-адрес. DNS-преобразователи помогают это сделать.

На что настроен ваш DNS преобразователь

Большинство домашних пользователей используют распознаватель DNS, который им назначает поставщик услуг Интернета (ISP). Обычно он назначается автоматически при настройке кабельного / DSL-модема или когда ваш беспроводной / проводной интернет-маршрутизатор автоматически подключается к DHCP-серверу вашего интернет-провайдера и получает IP-адрес для использования вашей сетью.

Обычно вы можете узнать, какой DNS-распознаватель вам назначен, перейдя на страницу подключения «WAN» вашего маршрутизатора и в разделе «DNS-серверы». Обычно их два, основной и альтернативный. Эти DNS-серверы могут быть размещены вашим провайдером или нет.

Вы также можете увидеть, какой DNS-сервер используется вашим компьютером, открыв командную строку, набрав nslookup и нажав клавишу Enter. Вы должны увидеть имя и IP-адрес «DNS-сервера по умолчанию».

Зачем использовать альтернативный DNS

Возможно, вы захотите переключиться с серверов DNS, предоставляемых интернет-провайдером, на альтернативу, по нескольким причинам:

Причина №1 – альтернативные DNS могут повысить скорость просмотра веб-страниц

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

Причина №2 – альтернативные DNS могут повысить безопасность

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

Причина №3 – некоторые DNS предлагают автоматическую фильтрацию содержимого

Хотите защитить ваших детей от доступа к «несемейному» контенту? Вы можете выбрать поставщика DNS, который выполняет фильтрацию содержимого. Например, Яндекс.DNS предлагает серверы DNS, которые отфильтровывают нежелательный контент.

Это не означает, что ваши дети не смогут просто ввести IP-адрес для неподходящего сайта и получить к нему доступ таким образом, но это добавит значительную преграду на пути поиска зрелого веб-контента.

Как переключите свой DNS Resolver

Лучший способ переключения DNS – настройка вашего маршрутизатора, так что вам нужно изменить его только в одном месте. После того, как вы измените его на своем маршрутизаторе, все клиенты в вашей сети (при условии, что вы используете DHCP для автоматического назначения IP-адресов клиентским устройствам) должны автоматически подключаться к новым DNS-серверам.

Обратитесь к справочному руководству вашего роутера за подробной информацией о том, как и где изменить записи вашего DNS-сервера.

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

Альтернативные DNS-провайдеры

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

Базовый: 77.88.8.8 и 77.88.8.1 – быстрый и надежный DNS
Безопасный: 77.88.8.88 и 77.88.8.2 – без мошеннических сайтов и вирусов
Семейный: 77.88.8.7 и 77.88.8.3 – без сайтов для взрослых

Google Public DNS:

Примечание относительно альтернативных DNS

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

Внимательный читатель найдет на этой картинке IPv6

Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.

Что такое DNS

DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.

Базовые штуки

Давайте взглянем на маппинг между именем и адресом:

Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:

Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:

dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов — AAAA . Давайте взглянем на ответ:

Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A : 192.241.250.244 . Число 300 это TTL , или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet . Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA's DNS Parameters.

Оставшаяся часть ответа описывает сам ответ:

В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес ( 192.168.1.1 ), на какой порт стучался dig ( 53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.

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

Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig 'у, если бы информация не был закэширована:

Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info ? Так вот, точка . это важная деталь, и она означает корень иерархии.

Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.

Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.

В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера ( 192.5.5.241 ). Так какой именно корневой сервер это был? Давайте узнаем!

Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!

Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.

Другие типы

Заметьте, что MX -запись указывает на имя, а не на IP-адрес.

Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:

Что не так с CNAME

Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.

Запросы к другим серверам

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

Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .

Типичные ситуации

Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

Редирект домена на www

CNAME для Heroku или Github

С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.

Wildcards

Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:

Заключение

Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:

Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.

TL;DR: DNS-резолвер в Windows 10 отправляет запросы на все известные системе адреса DNS-серверов параллельно, привязывая запрос к интерфейсу, и использует тот ответ, который пришел быстрее. В случае, если вы используете DNS-сервер из локального сегмента, такое поведение позволяет вашему провайдеру или злоумышленнику с Wi-Fi-точкой подменять записи DNS, даже если вы используете VPN.

Современные версии Windows добавляют головные боли активным пользователям VPN. DNS-резолвер до Windows 7 включительно имел предсказуемое поведение, совершая запросы к DNS-серверам в порядке очереди и приоритета DNS-серверов, в общем-то, как и все остальные ОС. Это создавало так называемый DNS Leak (утечка DNS-запроса через внешний интерфейс при подключенном VPN) только в том случае, если DNS-сервер внутри VPN-туннеля не ответил вовремя, или ответил ошибкой, и, в целом, не являлось такой уж вопиющей проблемой.

Windows 8

С выходом Windows 8, Microsoft добавила весьма интересную функцию в DNS-резолвер, которая, как я могу судить по Google, осталась совершенно незамеченной: Smart Multi-Homed Name Resolution. Если эта функция включена (а она включена по умолчанию), ОС отправляет запросы на все известные ей DNS-серверы на всех сетевых интерфейсах параллельно, привязывая запрос к интерфейсу. Сделано это было, вероятно, для того, чтобы уменьшить время ожидания ответа от предпочитаемого DNS-сервера в случае, если он по каким-то причинам не может ответить в отведенный ему таймаут (1 секунда по умолчанию), и сразу, по истечении таймаута, отдать ответ от следующего по приоритету сервера. Таким образом, в Windows 8 и 8.1 все ваши DNS-запросы «утекают» через интернет-интерфейс, позволяя вашему провайдеру или владельцу Wi-Fi-точки просматривать, на какие сайты вы заходите, при условии, что ваша таблица маршрутизации позволяет запросы к DNS-серверу через интернет-интерфейс. Чаще всего такая ситуация возникает, если использовать DNS-сервер внутри локального сегмента, такие DNS поднимают 99% домашних роутеров.

Данную функциональность можно отключить, добавив в ветку реестра:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient
Параметр типа DWORD с названием:
DisableSmartNameResolution
и любым значением, отличным от нуля, что возвращало старое поведение резолвера.

Windows 10

UPD: ранее в статье рекомендовалось использовать параметр redirect-gateway без def1 для OpenVPN. Оказывается, Windows возвращает маршрут по умолчанию от DHCP-сервера при каждом обновлении IP-адреса, и через какое-то время весь ваш трафик начинал бы ходить в обход VPN. На данный момент, красивого решения не существует.

Шифрование трафика между вашим устройством и DNS-сервисом помешает посторонним лицам отслеживать трафик или подменить адрес

Смерть сетевого нейтралитета и ослабление правил для интернет-провайдеров по обработке сетевого трафика вызвали немало опасений по поводу конфиденциальности. У провайдеров (и других посторонних лиц, которые наблюдают за проходящим трафиком) уже давно есть инструмент, позволяющий легко отслеживать поведение людей в интернете: это их серверы доменных имен (DNS). Даже если они до сих пор не монетизировали эти данные (или не подменяли трафик), то наверняка скоро начнут.

«Открытые» DNS-сервисы позволяют обходить сервисы провайдеров ради конфиденциальности и безопасности, а кое в каких странах — уклоняться от фильтрации контента, слежки и цензуры. 1 апреля (не шутка) компания Cloudflare запустила свой новый, бесплатный и высокопроизводительный DNS-сервис, предназначенный для повышения конфиденциальности пользователей в интернете. Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.

Названный по своему IP-адресу, сервис 1.1.1.1 — это результат партнёрства с исследовательской группой APNIC, Азиатско-Тихоокеанским сетевым информационным центром, одним из пяти региональных интернет-регистраторов. Хотя он также доступен как «открытый» обычный DNS-резолвер (и очень быстрый), но Cloudflare ещё поддерживает два протокола шифрования DNS.

Хотя и разработанный с некоторыми уникальными «плюшками» от Cloudflare, но 1.1.1.1 — никак не первый DNS-сервис с шифрованием. Успешно работают Quad9, OpenDNS от Cisco, сервис 8.8.8.8 от Google и множество более мелких сервисов с поддержкой различных схем полного шифрования DNS-запросов. Но шифрование не обязательно означает, что ваш трафик невидим: некоторые службы DNS с шифрованием всё равно записывают ваши запросы в лог для различных целей.

Cloudflare пообещал не журналировать DNS-трафик и нанял стороннюю фирму для аудита. Джефф Хастон из APNIC сообщил, что APNIC собирается использовать данные в исследовательских целях: диапазоны 1.0.0.0/24 и 1.1.1.0/24 изначально были сконфигурированы как адреса для «чёрного» трафика. Но APNIC не получит доступ к зашифрованному трафику DNS.

Для пользователей подключить DNS-шифрование не так просто, как изменить адрес в настройках сети. В настоящее время ни одна ОС напрямую не поддерживает шифрование DNS без дополнительного программного обеспечения. И не все сервисы одинаковы с точки зрения софта и производительности.

Как работает DNS

Есть много причин для лучшей защиты DNS-трафика. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как Transport Layer Security (TLS), но почти весь трафик DNS передаётся незашифрованным. Это означает, что ваш провайдер (или кто-то другой между вами и интернетом) может регистрировать посещаемые сайты даже при работе через сторонний DNS — и использовать эти данных в своих интересах, включая фильтрацию контента и сбор данных в рекламных целях.

Как выглядит типичный обмен данными между устройством и DNS-резолвером

«У нас есть проблема “последней мили” в DNS, — говорил Крикет Лю, главный архитектор DNS в компании Infoblox, которая занимается информационной безопасностью. — Большинство наших механизмов безопасности решают вопросы коммуникаций между серверами. Но есть проблема с суррогатами резолверов на различных операционных системах. В реальности мы не можем их защитить». Проблема особенно заметна в странах, где власти более враждебно относятся к интернету.

Наиболее очевидный способ уклонения от слежки — использование VPN. Но хотя VPN скрывают содержимое вашего трафика, для подключения к VPN может потребоваться запрос DNS. И в ходе VPN-сеанса запросы DNS тоже могут иногда направляться веб-браузерами или другим софтом за пределы VPN-тоннеля, создавая «утечки DNS», которые раскрывают посещённые сайты.

Однако эта опция защиты недоступна массовому пользователю. Ни один из этих протоколов нативно не поддерживается ни одним DNS-резолвером, который идёт в комплекте с ОС. Все они требуют установки (и, вероятно, компиляции) клиентского приложения, которое действует как локальный «сервер» DNS, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению к безопасному провайдеру DNS по вашему выбору. И хотя две из трёх данных технологий предлагаются на роль стандартов, ни один из проверенных нами вариантов пока не представлен в окончательном виде.

Поэтому если хотите погрузиться в шифрование DNS, то лучше взять для DNS-сервера в домашней сети Raspberry Pi или другое отдельное устройство. Потому что вы наверняка обнаружите, что настройка одного из перечисленных клиентов — это уже достаточно хакерства, чтобы не захотеть повторять процесс заново. Проще запросить настройки DHCP по локальной сети — и указать всем компьютерам на одну успешную установку DNS-сервера. Я много раз повторял себе это во время тестирования, наблюдая падение одного за другим клиентов под Windows и погружение в спячку клиентов под MacOS.

Сообщество DNSCrypt пыталось сделать доступный инструмент для тех, кто не обладает навыками работы в командной строке, выпустив программы DNSCloak (слева) под iOS и Simple DNSCrypt (справа) под Windows

Для полноты картины в исторической перспективе начнём обзор с самой первой технологии шифрования DNS — DNSCrypt. Впервые представленный в 2008 году на BSD Unix, инструмент DNSCrypt изначально предназначался для защиты не от прослушки, а от DNS-спуфинга. Тем не менее, его можно использовать как часть системы обеспечения конфиденциальности — особенно в сочетании с DNS-сервером без логов. Как отметил разработчик DNSCrypt Фрэнк Денис, гораздо больше серверов поддерживают DNSCrypt, чем любой другой вид шифрования DNS.

«DNSCrypt — это немного больше, чем просто протокол, — говорит Фрэнк Денис. — Сейчас сообщество и активные проекты характеризуют его гораздо лучше, чем мой изначальный протокол, разработанный в выходные». Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.

«DNSCrypt — это не подключение к серверам конкретной компании, — сказал Денис. — Мы призываем всех поднимать собственные сервера. Сделать это очень дёшево и легко. Теперь, когда у нас есть безопасные резолверы, я пытаюсь решить задачу фильтрации контента с учётом конфиденциальности».

Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. Старая версия DNSCrypt Proxy по-прежнему доступна как пакет для большинства основных дистрибутивов Linux, но лучше загрузить бинарник новой версии непосредственно с официального репозитория на GitHub. Есть версии для Windows, MacOS, BSD и Android.

Опыт сообщества DNSCrypt по защите конфиденциальности воплощён в DNSCrypt Proxy. Программа легко настраивается, поддерживает ограничения по времени доступа, шаблоны для доменов и чёрный список IP-адресов, журнал запросов и другие функции довольно мощного локального DNS-сервера. Но для начала работы достаточно самой базовой конфигурации. Есть пример файла конфигурации в формате TOML (Tom's Obvious Minimal Language, созданный соучредителем GitHub Томом Престоном-Вернером). Можете просто переименовать его перед запуском DNSCrypt Proxy — и он станет рабочим файлом конфигурации.

По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Затем подключается к серверу с самым быстрым откликом. При необходимости можно изменить конфигурацию и выбрать конкретный сервис. Информация о серверах в списке кодируется как «штамп сервера». Он содержит IP-адрес поставщика, открытый ключ, информацию, поддерживает ли сервер DNSSEC, хранит ли провайдер логи и блокирует ли какие-нибудь домены. (Если не хотите зависеть от удалённого файла при установке, то можно запустить «калькулятор штампов» на JavaScript — и сгенерировать собственный локальный статичный список серверов в этом формате).

Для своего тестирования DNSCrypt я использовал OpenDNS от Cisco в качестве удалённого DNS-сервиса. При первых запросах производительность DNSCrypt оказалась немного хуже, чем у обычного DNS, но затем DNSCrypt Proxy кэширует результаты. Самые медленные запросы обрабатывались в районе 200 мс, в то время как средние — примерно за 30 мс. (У вас результаты могут отличаться в зависимости от провайдера, рекурсии при поиске домена и других факторов). В целом, я не заметил замедления скорости при просмотре веб-страниц.

С другой стороны, DNSCrypt для шифрования не полагается на доверенные центры сертификации — клиент должен доверять открытому ключу подписи, выданному провайдером. Этот ключ подписи используется для проверки сертификатов, которые извлекаются с помощью обычных (нешифрованных) DNS-запросов и используются для обмена ключами с использованием алгоритма обмена ключами X25519. В некоторых (более старых) реализациях DNSCrypt есть условие для сертификата на стороне клиента, который может использоваться в качестве схемы управления доступом. Это позволяет им журналировать ваш трафик независимо от того, с какой IP-адреса вы пришли, и связывать его с вашим аккаунтом. Такая схема не используется в DNSCrypt 2.

С точки зрения разработчика немного сложно работать с DNSCrypt. «DNSCrypt не особенно хорошо документирован, и не так много его реализаций», — говорит Крикет Лю из Infoblox. На самом деле мы смогли найти только единственный клиент в активной разработке — это DNSCrypt Proxy, а OpenDNS прекратил поддерживать его разработку.

Интересный выбор криптографии в DNSCrypt может напугать некоторых разработчиков. Протокол использует Curve25519 (RFC 8032), X25519 (RFC 8031) и Chacha20Poly1305 (RFC 7539). Одна реализация алгоритма X24419 в криптографических библиотеках Pyca Python помечена как «криптографически опасная», потому что с ней очень легко ошибиться в настройках. Но основной используемый криптографический алгоритм Curve25519, является «одной из самых простых эллиптических кривых для безопасного использования», — сказал Денис.

Разработчик говорит, что DNSCrypt никогда не считался стандартом IETF, потому что был создан добровольцами без корпоративной «крыши». Представление его в качестве стандарта «потребовало бы времени, а также защиты на заседаниях IETF», — сказал он. «Я не могу себе этого позволить, как и другие разработчики, которые работают над ним в свободное время. Практически все ратифицированные спецификации, связанные с DNS, фактически написаны людьми из одних и тех же нескольких компаний, из года в год. Если ваш бизнес не связан с DNS, то действительно тяжело получить право голоса».

TLS стал приоритетом для CloudFlare, когда понадобилось усилить шифрование веб-трафика для защиты от слежки

У DNS по TLS (Transport Layer Security) несколько преимуществ перед DNSCrypt. Во-первых, это предлагаемый стандарт IETF. Также он довольно просто работает по своей сути — принимает запросы стандартного формата DNS и инкапсулирует их в зашифрованный TCP-трафик. Кроме шифрования на основе TLS, это по существу то же самое, что и отправка DNS по TCP/IP вместо UDP.

Существует несколько рабочих клиентов для DNS по TLS. Самый лучший вариант, который я нашел, называется Stubby, он разработан в рамках проекта DNS Privacy Project. Stubby распространяется в составе пакета Linux, но есть также версия для MacOS (устанавливается с помощью Homebrew) и версия для Windows, хотя работа над последней ещё не завершена.

Хотя мне удалось стабильно запускать Stubby на Debian после сражения с некоторыми зависимостями, этот клиент регулярно падал в Windows 10 и имеет тенденцию зависать на MacOS. Если вы ищете хорошее руководство по установке Stubby на Linux, то лучшая найденная мной документация — это пост Фрэнка Сантосо на Reddit. Он также написал shell скрипт для установки на Raspberry Pi.

Положительный момент в том, что Stubby допускает конфигурации с использованием нескольких служб на основе DNS по TLS. Файл конфигурации на YAML позволяет настроить несколько служб IPv4 и IPv6 и включает в себя настройки для SURFNet, Quad9 и других сервисов. Однако реализация YAML, используемая Stubby, чувствительна к пробелам, поэтому будьте осторожны при добавлении новой службы (например, Cloudflare). Сначала я использовал табы — и всё поломал.

Клиенты DNS по TLS при подключении к серверу DNS осуществляют аутентификацию с помощью простой инфраструктуры открытых ключей (Simple Public Key Infrastructure, SPKI). SPKI использует локальный криптографический хэш сертификата провайдера, обычно на алгоритме SHA256. В Stubby этот хэш хранится как часть описания сервера в файле конфигурации YAML, как показано ниже:

После установления TCP-соединения клиента с сервером через порт 853 сервер представляет свой сертификат, а клиент сверяет его с хэшем. Если всё в порядке, то клиент и сервер производят рукопожатие TLS, обмениваются ключами и запускают зашифрованный сеанс связи. С этого момента данные в зашифрованной сессии следуют тем же правилам, что и в DNS по TCP.

После успешного запуска Stubby я изменил сетевые настройки сети DNS, чтобы направлять запросы на 127.0.0.1 (localhost). Сниффер Wireshark хорошо показывает этот момент переключения, когда трафик DNS становится невидимым.

Переключаемся с обычного трафика DNS на шифрование TLS

Хотя DNS по TLS может работать как DNS по TCP, но шифрование TLS немного сказывается на производительности. Запросы dig к Cloudflare через Stubby у меня выполнялись в среднем около 50 миллисекунд (у вас результат может отличаться), в то время как простые DNS-запросы к Cloudflare получают ответ менее чем за 20 мс.

Здесь тоже имеется проблема с управлением сертификатами. Если провайдер удалит сертификат и начнёт использовать новый, то в настоящее время нет чистого способа обновления данных SPKI на клиентах, кроме вырезания старого и вставки нового сертификата в файл конфигурации. Прежде чем с этим разберутся, было бы полезно использовать какую-то схему управления ключами. И поскольку сервис работает на редком порту 853, то с высокой вероятностью DNS по TLS могут заблокировать на файрволе.

Google и Cloudflare, похоже, одинаково видят будущее зашифрованного DNS

Как Cloudflare, мы считаем, что туннели иллюстрируют операцию «Арго» лучше, чем Бен Аффлек

Дабы убедиться, что проблема именно в протоколе DoH, а не в программистах Cloudflare, я испытал два других инструмента. Во-первых, прокси-сервер от Google под названием Dingo. Его написал Павел Форемски, интернет-исследователь из Института теоретической и прикладной информатики Академии наук Польши. Dingo работает только с реализацией DoH от Google, но его можно настроить на ближайшую службу Google DNS. Это хорошо, потому что без такой оптимизации Dingo сожрал всю производительность DNS. Запросы dig в среднем выполнялись более 100 миллисекунд.

Это сократило время отклика примерно на 20%, то есть примерно до того показателя, как у Argo.

А оптимальную производительность DoH неожиданно показал DNSCrypt Proxy 2. После недавнего добавления DoH Cloudflare в курируемый список публичных DNS-сервисов DNSCrypt Proxy почти всегда по умолчанию подключается к Cloudflare из-за низкой задержки этого сервера. Чтобы убедиться, я даже вручную сконфигурировал его под резолвер Cloudflare для DoH, прежде чем запустить батарею dig-запросов.

Все запросы обрабатывались менее чем за 45 миллисекунд — это быстрее, чем собственный клиент Cloudflare, причём с большим отрывом. С сервисом DoH от Google производительность оказалась похуже: запросы обрабатывались в среднем около 80 миллисекунд. Это показатель без оптимизации на ближайший DNS-сервер от Google.

Я не Бэтмен, но моя модель угроз всё равно немного сложнее, чем у большинства людей

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

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

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

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

Читайте также: