DNS over TLS что это такое? Где можно использовать DNS over TLS? Какие последствия могут быть если не использовать DNS over TLS

В прошлых статьях я писал о DNS провайдерах и рассказывал для каждого провайдера в отдельной статье, но не все dns провайдеры(скажем так) используют DNS over TLS. Скажем 1.1.1.1 провайдер(резолвер) от компании CloudFlare о котором писал в статье самый быстрый dns сервис. Так вот CloudFlare использует DNS over TLS с самого начала открытия. А если брать Google dns сервис(провайдер, резолвер) то он начал использовать только не давно, приблизительно октябрь 2018 года на нем заработал DNS over TLS. Ранее Google dns анонсировал что будет использовать DNS over HTTPS о Google dns я также рассказывал в статье Фильтрация с помощью DNS от Google. О других сервис dns вы можете узнать из предложенных статей выше там будут ссылки, если вас интересуют к примеру Yandex dns

 

Что такое DNS over TLS?

DNS over TLS это туннель в котором посылаются запросы до выбранного вами dns сервиса(скажем 1.1.1.1) но только если dns сервис поддерживает такое соединение. Ну а какие dns сервис поддерживают такие соединения я говорил чуть выше их пять на данный момент ноябрь 2018 года. Говоря более конкретней если вы используете dns обычный скажем вашего интернет провайдера или сервиса который не поддерживает туннель то все запросы будут ему видны, куда вы ходите что посещаете. Таким образом провайдер может подменять ваши запросы на нужные ему, также делают и мошенники только перехватывая dns трафик. Конечно сей час любой dns сервис поддерживает https шифрования и ваш трафик попросту шифруется передавая его в обе стороны. Но время идет и надо думать о более безопасных методах и теперь помимо шифрования есть еще и туннель который создается между вами сервисом dns если он поддерживает

Как работает DNS over TLS?
 

Выполняется TLS-подключение скажем на порт TCP:853, проверка сертификата сервиса dns происходит с использованием системных корневых сертификатов, точно так же как HTTPS в браузере когда сайты посещаете, как пример я рассказывал в статье Посещать сайты по HTTPS. Это избавляет от необходимости добавлять ключи вручную типо как проходить авторизацию, после как ключи проверенны и создается подключение между вашим пк и сервисом dns(резолвером) создается уже туннель ну а внутри тоннеля выполняется обычный DNS-запрос. Это создает меньше накладных расходов по сравнению с DNS over HTTPS, который добавляет HTTP-заголовки к запросу и ответу. На текущий момент только в Android 9 (Pie) о котором я не давно тоже рассказывал в статье Какие смартфоны получат обновления до Pie, поддержка DNS over TLS встроена в системный резолвер. Инструкция по настройке для Android 9, правда на английском есть на сервисе dns 1.1.1.1 переходим если надо. Для остальных систем предлагается использовать сторонний демон, а системный резолвер направлять на localhost (127.0.0.1) это как пример о нем в статье dns crypt только там шифрование https но принцип настройки тот же и если руки есть можно настроить таким образом, только логика еще потребуется. DNS через TLS поддерживается основными поставщиками DNS. что не относится к DNSCrypt. Хранитель DNSCrypt не поддерживал его, закрыл репозиторий на GitHub? и поставить домен в продажу. Репозиторий уже клонирован и теперь поддерживается Dyne, и они не планируют добавлять какие-либо новые функции, поэтому DNSCrypt отказывается в пользу стандарта «DNS over TLS». И в отличие от DNSCrypt, «DNS over TLS» имеет стандарт RFC

Разница между DNSCrypt, DNSSEC, DNS over TLS/HTTPS

DNS over SSH

Полное шифрование протокола DNS Может быть развернута в любой системе, на которой уже запущен SSH-сервер Боевой тест, широко используемый транспортный протокол Не зависит от корневых центров сертификации Может использовать DNSSEC или частные CA для проверки открытого ключа Поддерживает множественные механизмы аутентификации Не требует стека TLS; в современных реализациях даже не требуется OpenSSL

Минусы

Очень сложно настроить безопасно Требуется TCP Текущие реализации не масштабируются хорошо на стороне сервера Запросы UDP требуют инкапсуляции TCP Протокол SFTP поддерживает переупорядочение и параллелизм, но обычное туннелирование DNS-over-SSH не может использовать это

DNS over TLS (RFC7858)

Полное шифрование протокола DNS Имеет низкое, но все большее число серверов в развертывании Частично указано как RFC Many реализации, выполненные на разных этапах Предоставляет больше информации, чем обычный DNS для операторов-резольверов, чтобы отпечатать клиентов, и это (намеренно?) никогда не рассматривалось в спецификации

Минусы

Использует выделенный порт (853), который может быть заблокирован или контролироваться в ситуациях, когда шифрование DNS полезно Первоначальное соединение происходит медленно из-за длинного рукопожатия (до тех пор, пока не будет развернуто TLS 1.3, что может занять время из-за промежуточных блоков) Не понимают даже его сторонники. Это грузовик, поскольку он тяжелый и медленный для загрузки, но большинство, если не все реализации, выполняют полный раунд для каждого пакета (даже отличную библиотеку miekg / dns, используемую Tenta). Правила заполнения не были указаны кроме черновика, который не имеет реализаций, и взлом в последнюю минуту, который требует изменения наборов записей DNS перед их переносом Требуется полный стек TLS, представляющий большую поверхность атаки Трудно реализовать безопасно. Проверка сертификатов TLS в не-браузерном программном обеспечении является самым опасным кодом в мире Легко совместим с отраслевыми, стандартные устройства перехвата / контроля TLS. Наличие людей для установки дополнительных корневых сертификатов проще, чем пользовательское программное обеспечение. Поставщики всегда готовы пассивно извлекать информацию из сеансов TLS 1.3. Требуется TCP Требуется отслеживание сеансов на сервере TLS - общий механизм транспорта. Он не поддерживает пере упорядочение и параллелизм и не включает в себя какие-либо способы управления приоритетами. Для этого необходимо изобрести и внедрить новые механизмы. Управление ключами может быть на удивление жестким, особенно если использование ключей открытого ключа используется клиентами Позволяет использовать небезопасные алгоритмы и параметры Будет сложно улучшить, не вводя больше хаков. Вряд ли можно извлечь выгоду из любых улучшений, помимо новых версий TLS или внутренних изменений. Сомнительные практические преимущества перед DoH
 

DNS over HTTPS (DoH)

Полное шифрование протокола DNS Разрабатываются новые реализации Минимальная версия HTTP, используемая DoH, должна быть HTTP / 2 Использует стандартный HTTP / 2, стандартный порт (443) автоматически получит выгоду от улучшений, сделанных в HTTP / 2, и, в конечном итоге, QUIC Меньше вероятность блокировки других опций Может быть тривиально развернут на любом веб-сервере и работать по существующим веб-сайтам; Ответ DNS обрабатывается как простые веб-страницы Может совместно использовать ту же инфраструктуру, что и существующие веб-сайты, и использовать одни и те же сертификаты Простая реализация поверх любого существующего веб-стека Немедленно совместим с кешированием прокси и CDN Позволяет веб-браузерам выполнять DNS-запросы с помощью Javascript Поддерживает переупорядочение, параллельность и приоритеты благодаря HTTP / 2 Может использовать существующие механизмы заполнения (заполнение HTTP / 2 кадра) Уже реализован Google DNS (хотя и не последний проект) Поддерживается CuRL: скоро будет доступен на всех языках программирования с привязками для libcurl Доступно в Firefox Ведется работа по использованию DoH и CDN для повышения производительности веб-приложений. DoH digests Указывается как RFC

Минусы

Предоставляет больше информации, чем обычный DNS для операторов-резольверов, чтобы отпечатать клиентов, но это рассматривается в спецификации Требуется полный стек TLS и веб-сервер Инструменты перехвата / мониторинга доступны Управление ключами может быть на удивление жестким, особенно если использование ключей открытого ключа используется клиентами Позволяет использовать небезопасные алгоритмы и параметры Требуется TCP

DNS-over-DTLS (RFC8094)

Минусы

Нет известных реализаций Множество уязвимостей безопасности в OpenSSL из-за DTLS
 

DNS over QUIC

Полное шифрование протокола DNS

Минусы

Использует выделенный порт: 784 RFC находится в черновом режиме

 

Все ссылки упоминающиеся в статье Вы сможете найти на странице статьи:

https://helpsetup.ru/internet/chto_takoe_DNS_over_TLS_i_kak_nastroit.html